Firepower Management Center Configuration Guide, Version 6.

3
First Published: 2018-12-03
Last Modified: 2019-02-18

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: www.cisco.com
go trademarks. 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)
© 2018–2019 Cisco Systems, Inc. All rights reserved.
 CONTENTS

CHAPTER 1 Getting Started With Firepower 1

Quick Start: Basic Setup 1
Installing and Performing Initial Setup on Physical Appliances 2
Deploying Virtual Appliances 3
Logging In for the First Time 4
Setting Up Basic Policies and Configurations 4
Firepower Devices 6
Firepower Features 7
Appliance and System Management Features 7
High Availability, Clustering, and Stacking Features by Appliance 8
Features for Detecting, Preventing, and Processing Potential Threats 9
Integration with External Tools 11
Firepower Online Help, How To, and Documentation 11
Top-Level Documentation Listing Pages for Firepower Management Center Deployments 12
License Statements in the Documentation 14
Supported Devices Statements in the Documentation 14
Access Statements in the Documentation 14
Firepower System IP Address Conventions 15
Additional Resources 15

PART I Your User Account 17

CHAPTER 2 Logging into the Firepower System 19

Firepower System User Accounts 19
User Interfaces in Firepower Management Center Deployments 21
Web Interface Considerations 23

Firepower Management Center Configuration Guide, Version 6.3

iii
 Contents

Session Timeout 24
Logging Into the Firepower Management Center Web Interface 24
Logging Into the Web Interface of a 7000 or 8000 Series Device 25
Logging Into the Firepower Management Center with CAC Credentials 26
Logging Into a 7000 or 8000 Series Device with CAC Credentials 27
Logging Into the Command Line Interface on Classic Devices 27
Logging Into the Command Line Interface on FTD Devices 28
Viewing Basic System Information in the Web Interface 30
Switching Domains on the Firepower Management Center 30
Logging Out of a Firepower System Web Interface 31
The Context Menu 31
History for Logging into the Firepower System 33

CHAPTER 3 Specifying User Preferences 35

User Preferences Introduction 35
Changing Your Password 35
Changing an Expired Password 36
Specifying Your Home Page 36
Configuring Event View Settings 37
Event View Preferences 37
File Download Preferences 39
Default Time Windows 39
Default Workflows 41
Setting Your Default Time Zone 41
Specifying Your Default Dashboard 42

CHAPTER 4 User Accounts for Management Access 43

About User Accounts 43
Internal and External Users 43
Web Interface, CLI, or Shell Access 44
User Roles 45
Web Interface User Roles 45
CLI User Roles 46
Prerequisites and Requirements for User Accounts 46

Firepower Management Center Configuration Guide, Version 6.3

iv
 Contents

Guidelines and Limitations for User Accounts 47

Add an Internal User Account 47
Add an Internal User at the Web Interface 47
Add an Internal User at the CLI 49
Configure External Authentication 51
About External Authentication 51
External Authentication for the Firepower Management Center and 7000 and 8000 Series 52
External Authentication for the Firepower Threat Defense 52
About LDAP 52
About RADIUS 52
Add an LDAP External Authentication Object 53

Add a RADIUS External Authentication Object 60

Enable External Authentication for Users on the Firepower Management Center 65
Enable External Authentication for Users on Managed Devices 66
Configure Common Access Card Authentication with LDAP 66
Customize User Roles for the Web Interface 68
Create Custom User Roles 68
Deactivate User Roles 70
Enable User Role Escalation 70
Set the Escalation Target Role 71
Configure a Custom User Role for Escalation 71
Escalate Your User Role 72
Configure Cisco Security Manager Single Sign-on 72
Troubleshooting LDAP Authentication Connections 73
History for User Accounts 75

PART II Firepower System Management 77

CHAPTER 5 Licensing the Firepower System 79

About Firepower Licenses 79
License Requirements for Firepower Management Center 79
Evaluation License Caveats 80
Smart vs. Classic Licenses 80
Licensing for Deployments with Firepower Threat Defense Devices (Smart Licensing) 81

Firepower Management Center Configuration Guide, Version 6.3

v
Contents

How to License Firepower Threat Defense Devices Managed by Firepower Management Center
81

Smart Software Manager 85

Periodic Communication with the License Authority 85
Service Subscriptions for Firepower Features (Smart Licensing) 85
Smart License Types and Restrictions 86
Base Licenses 88
Firepower Management Center Virtual Licenses 88
Malware Licenses for Firepower Threat Defense Devices 88
Threat Licenses 89
URL Filtering Licenses for Firepower Threat Defense Devices 89
AnyConnect Licenses 90
Licensing for Export-Controlled Functionality 91
Licensing for High-Availability Configurations 92
Licensing for FTD Clusters 92
Licensing for Multi-Instance Deployments 92
Create a Smart Account to Hold Your Licenses 93
Smart Licensing with Direct Internet Access 94
Obtain a Product License Registration Token for Smart Licensing 94
Register Smart Licenses 95
Enabling the Export Control Feature (for Accounts Without Global Permission) 96
Disabling the Export Control Feature (for Accounts without Global Permission) 98
Licensing Options for Air-Gapped Deployments 98
Smart Software Satellite Server Overview 99
How to Deploy a Smart Software Satellite Server 99
Specific License Reservation Overview 101
Best Practices for Specific License Reservation 101
Requirements for Specific License Reservation 101
How to Implement Specific License Reservation 101
Update a Specific License Reservation 107
Important! Maintain Your SLR Deployment 109
Specific License Reservation Status 109
Expired Specific License Reservation 110
Renew Specific License Reservation Entitlements 110

Firepower Management Center Configuration Guide, Version 6.3

vi
 Contents

Deactivate and Return the Specific License Reservation 111

Troubleshoot Specific License Reservation 113
Assign Licenses to Multiple Managed Devices 114
View Your Smart Licenses and Smart Licenses Status 115
Smart License Status 116
Move or Remove Smart Licenses from Managed Devices 117
Transfer Smart Licenses to a Different Firepower Management Center 117
If Smart License Status is Out of Compliance 117
Deregister a Firepower Management Center from the Cisco Smart Software Manager 118
Synchronize a Firepower Management Center with the Cisco Smart Software Manager 119
Troubleshoot Smart Licensing 119
Licensing for All Other Firepower Devices (Classic Licensing) 119
Product License Registration Portal 120
Service Subscriptions for Firepower Features (Classic Licensing) 120
Classic License Types and Restrictions 120
Protection Licenses 122
Control Licenses 122
URL Filtering Licenses for Classic Devices 123
Malware Licenses for Classic Devices 124
VPN Licenses 124
Classic Licenses in Device Stacks and High-Availability Pairs 125
View Your Classic Licenses 125
Identify the License Key 125
Generate a Classic License and Add It to the Firepower Management Center 126
How to Convert a Classic License or PAK to a Smart License 127
Assign Licenses to Managed Devices from the Device Management Page 129
Firepower License and Service Subscription Expiration 131
Other Licensing Information in This Guide 134
Additional Information about Firepower Licensing 135
Cisco Success Network 136
Cisco Success Network Telemetry Data 136
Enrolled Device Data 137
Software Version Data 138
Managed Device Data 138

Firepower Management Center Configuration Guide, Version 6.3

vii
 Contents

Deployment Information 139

Telemetry Example File 139
Changing Cisco Success Network Enrollment 141
End-User License Agreement 142
History for Licensing 142

CHAPTER 6 System Software Updates 145

About Firepower Updates 145
Guidelines and Limitations for Firepower Updates 146
Upgrade Firepower System Software 146
Update the Vulnerability Database (VDB) Manually 147
Update the Geolocation Database (GeoDB) 148
Manually Update the GeoDB (Internet Connection) 149
Manually Update the GeoDB (No Internet Connection) 149
Schedule GeoDB Updates 150
Update Intrusion Rules 150
Update Intrusion Rules One-Time Manually 152
Update Intrusion Rules One-Time Automatically 152
Configure Recurring Intrusion Rule Updates 153
Guidelines for Importing Local Intrusion Rules 154
Import Local Intrusion Rules 155
Rule Update Log 156
Intrusion Rule Update Log Table 156
Viewing the Intrusion Rule Update Log 156
Fields in an Intrusion Rule Update Log 157
Viewing Details of the Intrusion Rule Update Import Log 159
Maintain Your Air-Gapped Deployment 160

CHAPTER 7 Backup and Restore Introduction 161

Backup and Restore Support 161
Backup and Restore Guidelines and Limitations 162
Backup and Restore Guidelines and Limitations on Firepower Management Center and 7000, 8000
Series Devices 162
Backup and Restore Guidelines and Limitations on Firepower Threat Defense Devices 163

Firepower Management Center Configuration Guide, Version 6.3

viii
 Contents

Configuration Import/Export Guidelines for Firepower 4100/9300 164

VPN Certificate Management on Firepower Threat Defense 165

Backup Files 165
Backing Up a Firepower Management Center 166
Backing Up a 7000 or 8000 Series Device Locally 168
Backing Up Managed Devices from a Firepower Management Center 169
Creating Backup Profiles 170
Uploading Backups from a Local Host to a Firepower Management Center, 7000 or 8000 Series Device
171

The Backup Management Page 172

Restoring a Firepower Management Center, 7000 or 8000 Series Device from a Backup File 173
Backup and Restore a Firepower Threat Defense Device 175
Backup and Restore a Firepower 2100 Series Device 175
Backup and Restore a Firepower Threat Defense on a Firepower 4100 Series or Firepower 9300
device 176
Exporting an FXOS Configuration File 176
Backup and Restore a Firepower Threat Defense on a Firepower 4100 Series or Firepower 9300
device 177
Backup and Restore a Firepower Threat Defense on ASA 5500-X Series Device 180
Backup and Restore Firepower Threat Defense Devices in a High Availability Configuration 181

Backup and Restore a Firepower Threat Defense Device in a High Availability Pair 182

Backup and Restore Both Firepower Threat Defense Devices in a High Availability Pair 183

Backup and Restore a Firepower Threat Defense Virtual Device 185

CHAPTER 8 Configuration Import and Export 187

About Configuration Import/Export 187
Configurations that Support Import/Export 187
Special Considerations for Configuration Import/Export 188
Exporting Configurations 189
Importing Configurations 190
Import Conflict Resolution 191

CHAPTER 9 Task Scheduling 193

Introduction to Task Scheduling 193

Firepower Management Center Configuration Guide, Version 6.3

ix
 Contents

Configuring a Recurring Task 193

Backup Task Automation 194
Automating Firepower Management Center Backups 195
Automating Managed Device Backups 196
Configuring Certificate Revocation List Downloads 196
Automating Policy Deployment 197
Nmap Scan Automation 198
Scheduling an Nmap Scan 199
Automating Report Generation 200
Specify Report Generation Settings for a Scheduled Report 201
Automating Firepower Recommendations 202
Software Update Automation 203
Automating Software Downloads 204
Automating Software Pushes 204
Automating Software Installs 205
Vulnerability Database Update Automation 206
Automating VDB Update Downloads 207
Automating VDB Update Installs 207
Automating URL Filtering Updates Using a Scheduled Task 208
Scheduled Task Review 209
Task List Details 210
Viewing Scheduled Tasks on the Calendar 211
Editing Scheduled Tasks 211
Deleting Scheduled Tasks 212

CHAPTER 10 FMC Database Purge 213

Purging Data from the FMC Database 213

PART III System Monitoring and Troubleshooting 215

CHAPTER 11 Dashboards 217

About Dashboards 217
Firepower System Dashboard Widgets 218
Widget Availability 218

Firepower Management Center Configuration Guide, Version 6.3

x
 Contents

Dashboard Widget Availability by User Role 219

Predefined Dashboard Widgets 220
The Appliance Information Widget 220
The Appliance Status Widget 221
The Correlation Events Widget 221
The Current Interface Status Widget 221
The Current Sessions Widget 222
The Custom Analysis Widget 222
The Disk Usage Widget 226
The Interface Traffic Widget 227
The Intrusion Events Widget 227
The Network Compliance Widget 228
The Product Licensing Widget 228
The Product Updates Widget 229
The RSS Feed Widget 229
The System Load Widget 229
The System Time Widget 230
The White List Events Widget 230
Managing Dashboards 230
Adding a Dashboard Tab 231
Adding Widgets to a Dashboard 232
Configuring Widget Preferences 233
Creating Custom Dashboards 233
Custom Dashboard Options 233
Customizing the Widget Display 235
Editing Dashboards Options 235
Modifying Dashboard Time Settings 236
Renaming a Dashboard Tab 237
Viewing Dashboards 237

CHAPTER 12 Health Monitoring 239

About Health Monitoring 239
Health Modules 240
Configuring Health Monitoring 247

Firepower Management Center Configuration Guide, Version 6.3

xi
 Contents

Health Policies 248

Default Health Policy 248
Creating Health Policies 248
Applying Health Policies 249
Editing Health Policies 250
Deleting Health Policies 251
The Health Monitor Blacklist 251
Blacklisting Appliances 252
Blacklisting Health Policy Modules 253
Health Monitor Alerts 253
Health Monitor Alert Information 254
Creating Health Monitor Alerts 254
Editing Health Monitor Alerts 255
Deleting Health Monitor Alerts 256
Using the Health Monitor 256
Health Monitor Status Categories 257
Viewing Appliance Health Monitors 258
Running All Modules for an Appliance 259
Running a Specific Health Module 260
Generating Health Module Alert Graphs 260
Health Event Views 261
Viewing Health Events 261
Viewing Health Events by Module and Appliance 261
Viewing the Health Events Table 262
Hardware Alert Details for 7000 and 8000 Series Devices 263
The Health Events Table 265
History for Health Monitoring 266

CHAPTER 13 Monitoring the System 267

System Statistics 267
System Statistics Availability by Appliance 267
The Host Statistics Section 268
The Disk Usage Section 268
The Processes Section 268

Firepower Management Center Configuration Guide, Version 6.3

xii
 Contents

Process Status Fields 269

System Daemons 270
Executables and System Utilities 272
The SFDataCorrelator Process Statistics Section 275
The Intrusion Event Information Section 275
Viewing System Statistics 276

CHAPTER 14 Troubleshooting the System 279

First Steps for Troubleshooting 279
System Messages 279
Message Types 280
Message Management 281
Managing System Messages 282
Viewing Deployment Messages 283
Viewing Health Messages 284
Viewing Task Messages 285
Managing Task Messages 285
Configuring Notification Behavior 286
Health Monitor Reports for Troubleshooting 286
Producing Troubleshooting Files for Specific System Functions 287
Downloading Advanced Troubleshooting Files 288
General Troubleshooting 289
Advanced Troubleshooting for the Firepower Threat Defense Device 289
Using the FTD CLI from the Web Interface 289
Packet Tracer Overview 290
Use the Packet Tracer 290
Packet Capture Overview 291
Use the Capture Trace 292
Feature-Specific Troubleshooting 293

PART IV Deployment Management 295

CHAPTER 15 Domain Management 297

Introduction to Multitenancy Using Domains 297

Firepower Management Center Configuration Guide, Version 6.3

xiii
 Contents

Domains Terminology 298

Domain Properties 299
Managing Domains 300
Creating New Domains 301
Moving Data Between Domains 302
Moving Devices Between Domains 303

CHAPTER 16 Policy Management 305

Policy Deployment 305
Guidelines for Deploying Configuration Changes 306
Restart Warnings for Firepower Threat Defense Devices 307
Deploy Configuration Changes 308
Redeploy Existing Configurations to a Device 310
Snort® Restart Scenarios 311
Inspect Traffic During Policy Apply 311
Snort® Restart Traffic Behavior 312
Configurations that Restart the Snort Process When Deployed or Activated 313
Changes that Immediately Restart the Snort Process 315
Policy Comparison 316
Comparing Policies 316
Policy Reports 317
Generating Current Policy Reports 317
Out-of-Date Policies 318
Performance Considerations for Limited Deployments 319
Discovery Without Intrusion Prevention 319
Intrusion Prevention Without Discovery 320

CHAPTER 17 Rule Management: Common Characteristics 321

Introduction to Rules 321
Rule Condition Types 323
Rule Condition Mechanics 324
Interface Conditions 325
Configuring Interface Conditions 327
Network Conditions 328

Firepower Management Center Configuration Guide, Version 6.3

xiv
 Contents

Configuring Network Conditions 329

Tunnel Endpoint Conditions 330
Configuring Tunnel Endpoint Conditions 331
VLAN Conditions 331
Port and ICMP Code Conditions 332
Configuring Port Conditions 333
Encapsulation Conditions 334
Application Conditions (Application Control) 334
Configuring Application Conditions and Filters 336
Application Characteristics 338
Guidelines and Limitations for Application Control 338
Application-Specific Notes and Limitations 340
Troubleshoot Application Control Rules 340
URL Conditions (URL Filtering) 342
User, Realm, and ISE Attribute Conditions (User Control) 342
User Control Prerequisites 343
Configuring User and Realm Conditions 344
Configuring ISE Attribute Conditions 344
Troubleshoot User Control 345
Custom SGT Conditions 346
ISE SGT vs Custom SGT Rule Conditions 347
Autotransition from Custom SGTs to ISE SGTs 347
Configuring Custom SGT Conditions 348
Troubleshooting Custom SGT Conditions 348
Searching for Rules 349
Filtering Rules by Device 349
Identify Rules with Issues 350
Rule and Other Policy Warnings 351
Rule Performance Guidelines 352
Guidelines for Simplifying and Focusing Rules 352
Guidelines for Ordering Rules 353
Rule Preemption 353
Rule Actions and Rule Order 354
Content Restriction Rule Order 355

Firepower Management Center Configuration Guide, Version 6.3

xv
 Contents

Application Rule Order 355

SSL Rule Order 355
URL Rule Order 356
Guidelines for Avoiding Intrusion Policy Proliferation 356
Offload Large Connections (Flows) 357
Flow Offload Limitations 358
History for Rule Management: Common Characteristics 360

CHAPTER 18 Reusable Objects 361

Introduction to Reusable Objects 362
The Object Manager 364
Editing Objects 364
Filtering Objects or Object Groups 365
Sorting Objects 366
Object Groups 366
Grouping Reusable Objects 366
Object Overrides 368
Managing Object Overrides 369
Allowing Object Overrides 369
Adding Object Overrides 370
Editing Object Overrides 370
Network Objects 371
Creating Network Objects 372
Port Objects 373
Creating Port Objects 374
Tunnel Zones 375
Application Filters 375
VLAN Tag Objects 375
Creating VLAN Tag Objects 375
Security Group Tag Objects 376
Creating Security Group Tag Objects 376
URL Objects 377
Creating URL Objects 377
Geolocation Objects 378

Firepower Management Center Configuration Guide, Version 6.3

xvi
 Contents

Creating Geolocation Objects 378

Interface Objects: Interface Groups and Security Zones 379
Creating Security Zone and Interface Group Objects 380
Time Range Objects 381
Creating Time Range Objects 381
Variable Sets 382
Variable Sets in Intrusion Policies 383
Variables 383
Predefined Default Variables 384
Network Variables 386
Port Variables 388
Advanced Variables 389
Variable Reset 389
Adding Variables to Sets 390
Nesting Variables 391
Managing Variable Sets 393
Creating Variable Sets 394
Managing Variables 394
Adding Variables 396
Editing Variables 397
Security Intelligence Lists and Feeds 398
Security Intelligence Object Quick Reference 399
Blacklist Now, Whitelist Now, and Global Lists 399
Security Intelligence Lists and Multitenancy 400
Changing the Update Frequency for Security Intelligence Feeds 401
Custom Security Intelligence Feeds 402
Creating Security Intelligence Feeds 403
Manually Updating Security Intelligence Feeds 403
Custom Security Intelligence Lists 404
Uploading New Security Intelligence Lists to the Firepower Management Center 404
Updating Security Intelligence Lists 405
Sinkhole Objects 406
Creating Sinkhole Objects 406
File Lists 407

Firepower Management Center Configuration Guide, Version 6.3

xvii
Contents

Source Files for File Lists 407

Adding Individual SHA-256 Values to File Lists 408
Uploading Individual Files to File Lists 409
Uploading Source Files to File Lists 410
Editing SHA-256 Values in File Lists 411
Downloading Source Files from File Lists 412
Cipher Suite Lists 412
Creating Cipher Suite Lists 413
Distinguished Name Objects 413
Creating Distinguished Name Objects 415
PKI Objects 415
Internal Certificate Authority Objects 416
CA Certificate and Private Key Import 417
Importing a CA Certificate and Private Key 417
Generating a New CA Certificate and Private Key 418
New Signed Certificates 419
Creating an Unsigned CA Certificate and CSR 419
Uploading a Signed Certificate Issued in Response to a CSR 419
CA Certificate and Private Key Downloads 420
Downloading a CA Certificate and Private Key 421
Trusted Certificate Authority Objects 421
Trusted CA Object 422
Adding a Trusted CA Object 422
Certificate Revocation Lists in Trusted CA Objects 423
Adding a Certificate Revocation List to a Trusted CA Object 423
External Certificate Objects 424
Adding External Certificate Objects 424
Internal Certificate Objects 425
Adding Internal Certificate Objects 425
Certificate Enrollment Objects 426
Adding Certificate Enrollment Objects 427
Certificate Enrollment Object SCEP Options 429
Certificate Enrollment Object Certificate Parameters 429
Certificate Enrollment Object Key Options 430

Firepower Management Center Configuration Guide, Version 6.3

xviii
 Contents

Certificate Enrollment Object Revocation Options 431

DNS Server Group Objects 431
Creating DNS Server Group Objects 432
SLA Monitor Objects 432
Prefix Lists 434
Configure IPv6 Prefix List 434
Configure IPv4 Prefix List 435
Route Maps 436
Access List 439
Configure Extended ACL Objects 439
Configure Standard ACL Objects 441
AS Path Objects 442
Community Lists 442
Policy Lists 444
VPN Objects 445
FTD IKE Policies 445
Configure IKEv1 Policy Objects 445
Configure IKEv2 Policy Objects 447

FTD IPsec Proposals 448

Configure IKEv1 IPsec Proposal Objects 449
Configure IKEv2 IPsec Proposal Objects 449
FTD Group Policy Objects 450
Configure Group Policy Objects 451
Group Policy General Options 452
Group Policy AnyConnect Options 453
Group Policy Advanced Options 455
FTD File Objects 456
FTD Certificate Map Objects 457
Address Pools 458
FlexConfig Objects 459
RADIUS Server Groups 459
RADIUS Server Group Options 460
RADIUS Server Options 461

Firepower Management Center Configuration Guide, Version 6.3

xix
 Contents

CHAPTER 19 Firepower Threat Defense Certificate-Based Authentication 463

Firepower Threat Defense VPN Certificate Guidelines and Limitations 463
Managing FTD Certificates 464
Installing a Certificate Using Self-Signed Enrollment 465

Installing a Certificate Using SCEP Enrollment 466

Installing a Certificate Using Manual Enrollment 467
Installing a Certificate Using a PKCS12 File 468
Troubleshooting FTD Certificates 468

PART V Appliance Management Basics 471

CHAPTER 20 Firepower Management Center Basics 473

The Firepower Management Center 473
Device Management 473
What Can Be Managed by a Firepower Management Center? 474
Beyond Policies and Events 474
NAT Environments 475

CHAPTER 21 Firepower Management Center High Availability 477

About Firepower Management Center High Availability 477
System Requirements Firepower Management Center High Availability 478

Hardware Requirements 478

Software Requirements 478
License Requirements 479
Roles v. Status in Firepower Management Center High Availability 479
Prerequisites to Establish Firepower Management Center High Availability 480
Event Processing on Firepower Management Center High Availability Pairs 480
AMP Cloud Connections and Malware Information 480
URL Filtering and Security Intelligence 480
User Data Processing During Firepower Management Center Failover 481
Configuration Management on Firepower Management Center High Availability Pairs 481
Cisco Threat Intelligence Director (TID) and High Availability Configurations 481
Firepower Management Center High Availability Behavior During a Backup 481

Firepower Management Center Configuration Guide, Version 6.3

xx
 Contents

Firepower Management Center High Availability Split-Brain 481

Upgrading Firepower Management Centers in a High Availability Pair 482
Troubleshooting Firepower Management Center High Availability 483
Establishing Firepower Management Center High Availability 483
Viewing Firepower Management Center High Availability Status 485
Configuration Data Synced between Firepower Management Centers during High Availability 486
Using CLI to Resolve Device Registration in Firepower Management Center High Availability 487
Switching Peers in a Firepower Management Center High Availability Pair 487
Pausing Communication Between Paired Firepower Management Centers 488
Restarting Communication Between Paired Firepower Management Centers 489
Changing the IP address of a Firepower Management Center in a High Availability Pair 489
Disabling Firepower Management Center High Availability 490
Replacing Firepower Management Centers in a High Availability Pair 491
Replace a Failed Primary Firepower Management Center (Successful Backup) 491
Replace a Failed Primary Firepower Management Center (Unsuccessful Backup) 493
Replace a Failed Secondary Firepower Management Center (Successful Backup) 494
Replace a Failed Secondary Firepower Management Center (Unsuccessful Backup) 495

CHAPTER 22 Device Management Basics 497

The Device Management Page 497
Filtering Managed Devices 498
Remote Management Configuration 498
Add Devices to the Firepower Management Center 499
Deleting Devices from the Firepower Management Center 501
Device Configuration Settings 502
General Device Settings 502
Device License Settings 502
Device System Settings 502
Device Health Settings 503
Device Management Settings 504
Advanced Device Settings 504
Viewing Device Information 505
Editing Device Management Settings 505
Editing General Device Settings 506

Firepower Management Center Configuration Guide, Version 6.3

xxi
 Contents

Copying Device Configurations 507

Enabling and Disabling Device Licenses 508
Editing Advanced Device Settings 509
Configuring Automatic Application Bypass 509
Inspecting Local Router Traffic 510
Configuring Fastpath Rules (8000 Series) 511
Managing System Shut Down 512
The Interfaces Table View 513
Device Group Management 515
Adding Device Groups 516
Editing Device Groups 516
Configuring SNMP for the Firepower 2100 Series 517
Enabling SNMP and Configuring SNMP Properties for Firepower 2100 517

Creating an SNMP Trap for Firepower 2100 518

Creating an SNMP User for Firepower 2100 519

PART VI Classic Device Configuration Basics 521

CHAPTER 23 Classic Device Management Basics 523

Remote Management Configuration 523
Configuring Remote Management on a Managed Device 524
Editing Remote Management on a Managed Device 524
Changing the Management Port 525
Interface Configuration Settings 526
The Physical Hardware View 526
Interface Icons 526
Using the Physical Hardware View 527
Configuring Sensing Interfaces 528
Configuring HA Link Interfaces 529
Disabling Interfaces 530
Managing Cisco ASA FirePOWER Interfaces 531
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv 532
Synchronizing Security Zone Object Revisions 532

Firepower Management Center Configuration Guide, Version 6.3

xxii
 Contents

CHAPTER 24 IPS Device Deployments and Configuration 535

Introduction to IPS Device Deployment and Configuration 535
Passive IPS Deployments 535
Passive Interfaces on the Firepower System 535
Configuring Passive Interfaces 536
Inline IPS Deployments 537
Inline Interfaces on the Firepower System 538
Configuring Inline Interfaces 539
Inline Sets on the Firepower System 540
Viewing Inline Sets 541
Adding Inline Sets 542
Advanced Inline Set Options 543
Configuring Advanced Inline Set Options 544
Deleting Inline Sets 545

PART VII Classic Device High Availability and Scalability 547

CHAPTER 25 7000 and 8000 Series Device High Availability 549

About 7000 and 8000 Series Device High Availability 549
Device High Availability Requirements 550
Device High Availability Failover and Maintenance Mode 550
Configuration Deployment and Upgrade Behavior for High-Availability Pairs 551
Deployment Types and Device High Availability 551
Device High Availability Configuration 553
Establishing Device High Availability 553
Editing Device High Availability 554
Configuring Individual Devices in a High-Availability Pair 555
Configuring Individual Device Stacks in a High-Availability Pair 555
Configuring Interfaces on a Device in a High-Availability Pair 556
Switching the Active Peer in a Device High-Availability Pair 557
Placing a High-Availability Peer into Maintenance Mode 557
Replacing a Device in a Stack in a High-Availability Pair 558
Device High Availability State Sharing 558

Firepower Management Center Configuration Guide, Version 6.3

xxiii
 Contents

Establishing Device High-Availability State Sharing 560

Device High Availability State Sharing Statistics for Troubleshooting 561
Viewing Device High Availability State Sharing Statistics 563
Separating Device High-Availability Pairs 564

CHAPTER 26 8000 Series Device Stacking 565

About Device Stacks 565
Device Stack Configuration 567
Establishing Device Stacks 568
Editing Device Stacks 569
Replacing a Device in a Stack 569
Replacing a Device in a Stack in a High-Availability Pair 570
Configuring Individual Devices in a Stack 571
Configuring Interfaces on a Stacked Device 571
Separating Stacked Devices 572
Replacing a Device in a Stack 573

PART VIII Firepower Threat Defense Getting Started 575

CHAPTER 27 Transparent or Routed Firewall Mode for Firepower Threat Defense 577
About the Firewall Mode 577
About Routed Firewall Mode 577
About Transparent Firewall Mode 578
Using the Transparent Firewall in Your Network 578
Diagnostic Interface 578
Passing Traffic For Routed-Mode Features 579
About Bridge Groups 579
Bridge Virtual Interface (BVI) 579
Bridge Groups in Transparent Firewall Mode 579
Bridge Groups in Routed Firewall Mode 580
Allowing Layer 3 Traffic 581
Allowed MAC Addresses 581
BPDU Handling 581
MAC Address vs. Route Lookups 582

Firepower Management Center Configuration Guide, Version 6.3

xxiv
 Contents

Unsupported Features for Bridge Groups in Transparent Mode 583

Unsupported Features for Bridge Groups in Routed Mode 584
Default Settings 585
Guidelines for Firewall Mode 585
Set the Firewall Mode 586

CHAPTER 28 Logical Devices for the Firepower Threat Defense on the Firepower 4100/9300 589
About Firepower Interfaces 589
Chassis Management Interface 589
Interface Types 590
Independent Interface States in the Chassis and in the Application 590
Shared Interface Scalability 591
Shared Interface Best Practices 591
Shared Interface Usage Examples 592
Viewing Shared Interface Resources 598
Inline Set Link State Propagation for the Firepower Threat Defense 598
About Logical Devices 599
Standalone and Clustered Logical Devices 599
Container Instances and Native Instances 599
Container Instance Interfaces 600
How the Chassis Classifies Packets 600
Classification Examples 600
Cascading Container Instances 604
Typical Multi-Instance Deployment 605
Automatic MAC Addresses for Container Instance Interfaces 606
Container Instance Resource Management 607
Container Instances and High Availability 607
Licenses for Container Instances 607
Requirements and Prerequisites for Container Instances 608
Guidelines and Limitations for Logical Devices 609
Guidelines and Limitations for Firepower Interfaces 609
General Guidelines and Limitations 611
Configure Interfaces 611
Enable or Disable an Interface 612

Firepower Management Center Configuration Guide, Version 6.3

xxv
 Contents

Configure a Physical Interface 612

Add an EtherChannel (Port Channel) 613
Add a VLAN Subinterface for Container Instances 614
Configure Logical Devices 616
Add a Resource Profile for Container Instances 616
Add a Standalone Firepower Threat Defense 617
Add a High Availability Pair 619
Change an Interface on a Firepower Threat Defense Logical Device 620
Connect to the Console of the Application 622
History for Firepower Threat Defense Logical Devices 624

PART IX Firepower Threat Defense Interfaces and Device Settings 629

CHAPTER 29 Interface Overview for Firepower Threat Defense 631

Management/Diagnostic Interface 631
Management Interface 631
Diagnostic Interface 631
Interface Mode and Types 632
Security Zones and Interface Groups 633
Auto-MDI/MDIX Feature 633
Default Settings for Interfaces 634
Enable the Physical Interface and Configure Ethernet Settings 634
Sync Interface Changes with the Firepower Management Center 636

CHAPTER 30 Regular Firewall Interfaces for Firepower Threat Defense 637

Configure EtherChannel and Redundant Interfaces 637
About EtherChannels and Redundant Interfaces 637
Redundant Interfaces 637
EtherChannels 638
Guidelines for EtherChannels and Redundant Interfaces 640
Configure a Redundant Interface 642
Configure an EtherChannel 643
Configure VLAN Subinterfaces and 802.1Q Trunking 645
Guidelines and Limitations for VLAN Subinterfaces 645

Firepower Management Center Configuration Guide, Version 6.3

xxvi
 Contents

Maximum Number of VLAN Subinterfaces by Device Model 645

Add a Subinterface 646
Configure Routed and Transparent Mode Interfaces 647
About Routed and Transparent Mode Interfaces 647
Routed Mode Deployment 647
Transparent Mode Deployment 649
Dual IP Stack (IPv4 and IPv6) 649
Guidelines and Requirements for Routed and Transparent Mode Interfaces 649
Configure Routed Mode Interfaces 651
Configure Bridge Group Interfaces 653
Configure General Bridge Group Member Interface Parameters 653
Configure the Bridge Virtual Interface (BVI) 654
Configure a Diagnostic (Management) Interface for Transparent Mode 656
Configure IPv6 Addressing 657
About IPv6 657
Configure a Global IPv6 Address 658
Configure IPv6 Neighbor Discovery 661
Configure Advanced Interface Settings 663
About Advanced Interface Configuration 663
About MAC Addresses 663
About the MTU 664
About the TCP MSS 665
ARP Inspection for Bridge Group Traffic 666
MAC Address Table for Bridge Groups 667
Default Settings 667
Guidelines for ARP Inspection and the MAC Address Table 667
Configure the MTU 668
Configure the MAC Address 669
Add a Static ARP Entry 670
Add a Static MAC Address and Disable MAC Learning for a Bridge Group 671
Set Security Configuration Parameters 672
History for Regular Firewall Interfaces for Firepower Threat Defense 674

CHAPTER 31 Inline Sets and Passive Interfaces for Firepower Threat Defense 677

Firepower Management Center Configuration Guide, Version 6.3

xxvii
 Contents

About Hardware Bypass for Inline Sets 677

Hardware Bypass Triggers 677
Hardware Bypass Switchover 678
Snort Fail Open vs. Hardware Bypass 678
Hardware Bypass Status 678
Prerequisites for Inline Sets 678
Guidelines for Inline Sets and Passive Interfaces 679
Configure a Passive Interface 679
Configure an Inline Set 681
History for Inline Sets and Passive Interfaces for Firepower Threat Defense 684

CHAPTER 32 DHCP and DDNS Services for Threat Defense 685

About DHCP and DDNS Services 685
About the DHCPv4 Server 685
DHCP Options 685
About the DHCP Relay Agent 686
About DDNS 686
DDNS Update Configurations 686
UDP Packet Size 687
Guidelines for DHCP and DDNS Services 687
Configure the DHCP Server 688
Configure the DHCP Relay Agent 690
Configure DDNS 691

CHAPTER 33 Quality of Service (QoS) for Firepower Threat Defense 693

Introduction to QoS 693
About QoS Policies 693
Rate Limiting with QoS Policies 694
Creating a QoS Policy 695
Setting Target Devices for a QoS Policy 696
Configuring QoS Rules 696
QoS Rule Components 697
History for QOS 699

Firepower Management Center Configuration Guide, Version 6.3

xxviii
 Contents

PART X Firepower Threat Defense High Availability and Scalability 701

CHAPTER 34 High Availability for Firepower Threat Defense 703

About Firepower Threat Defense High Availability 703
High Availability System Requirements 703
Hardware Requirements 703
Software Requirements 704
License Requirements for FTD Devices in a High Availability Pair 704
Failover and Stateful Failover Links 704
Failover Link 705
Stateful Failover Link 706
Avoiding Interrupted Failover and Data Links 706
MAC Addresses and IP Addresses in High Availability 708
Stateful Failover 709
Supported Features 709
Unsupported Features 711
Bridge Group Requirements for High Availability 711
Failover Health Monitoring 712
Unit Health Monitoring 712
Interface Monitoring 712
Failover Triggers and Detection Timing 714
About Active/Standby Failover 714
Primary/Secondary Roles and Active/Standby Status 714
Active Unit Determination at Startup 715
Failover Events 715
Guidelines for High Availability 716
Add a Firepower Threat Defense High Availability Pair 717
Configure Optional High Availability Parameters 719
Configure Standby IP Addresses and Interface Monitoring 719
Edit High Availability Failover Criteria 720
Configure Virtual MAC addresses 720
Manage High Availability 721
Switch the Active Peer in a Firepower Threat Defense High Availability Pair 721

Firepower Management Center Configuration Guide, Version 6.3

xxix
 Contents

Refresh node status in a Firepower Threat Defense High Availability pair 722
Suspend and Resume High Availability 723
Replace a Unit 724
Replace a Primary Unit 724
Replace a Secondary Unit 724
Separate Units in a High Availability Pair 725
Unregister a High Availability Pair 726
Monitoring High Availability 727
View Failover History 727
View Stateful Failover Statistics 727

CHAPTER 35 Clustering for the Firepower Threat Defense 729

About Clustering on the Firepower 4100/9300 Chassis 729
Bootstrap Configuration 730
Cluster Members 730
Cluster Control Link 730
Size the Cluster Control Link for Inter-Chassis Clustering 730
Cluster Control Link Redundancy for Inter-Chassis Clustering 731
Cluster Control Link Reliability for Inter-Chassis Clustering 731
Cluster Control Link Network 732
Management Network 732
Management Interface 732
Cluster Interfaces 732
Spanned EtherChannels 732
Connecting to a VSS or vPC 733
Configuration Replication 733
Firepower Threat Defense Features and Clustering 733
Unsupported Features with Clustering 733
Centralized Features for Clustering 734
Dynamic Routing and Clustering 734
NAT and Clustering 735
SIP Inspection and Clustering 736
Syslog and Clustering 736
SNMP and Clustering 736

Firepower Management Center Configuration Guide, Version 6.3

xxx
 Contents

FTP and Clustering 736

Cisco TrustSec and Clustering 736
VPN and Clustering 736
Licenses for Clustering 737
Requirements and Prerequisites for Clustering 737
Clustering Guidelines and Limitations 738
Configure Clustering 742
FXOS: Add a Firepower Threat Defense Cluster 742
Create a Firepower Threat Defense Cluster 742
Add More Cluster Members 745
FMC: Add a Cluster 747
FMC: Configure Data and Diagnostic Interfaces 748
Manage Cluster Members 749
Add a New Cluster Member 750
Replace a Cluster Member 750
Delete a Slave Member 752
Reconcile Cluster Members 752
Rejoin the Cluster 753
FMC: Monitoring the Cluster 753
Reference for Clustering 754
Performance Scaling Factor 754
Master Unit Election 754
High Availability Within the Cluster 755
Chassis-Application Monitoring 755
Unit Health Monitoring 755
Interface Monitoring 755
Status After Failure 756
Rejoining the Cluster 756
Data Path Connection State Replication 756
How the Cluster Manages Connections 757
Connection Roles 757
New Connection Ownership 758
Sample Data Flow 758
History for Clustering 759

Firepower Management Center Configuration Guide, Version 6.3

xxxi
 Contents

PART XI Firepower Threat Defense Routing 761

CHAPTER 36 Routing Overview for Firepower Threat Defense 763

Path Determination 763
Supported Route Types 764
Static Versus Dynamic 764
Single-Path Versus Multipath 764
Flat Versus Hierarchical 764
Link-State Versus Distance Vector 765
Supported Internet Protocols for Routing 765
Routing Table 766
How the Routing Table Is Populated 766
Administrative Distances for Routes 766
Backup Dynamic and Floating Static Routes 767
How Forwarding Decisions Are Made 768
Dynamic Routing and High Availability 768
Dynamic Routing in Clustering 768
Routing Table for Management Traffic 769
Equal-Cost Multi-Path (ECMP) Routing 770
About Route Maps 770
Permit and Deny Clauses 771
Match and Set Clause Values 771

CHAPTER 37 Static and Default Routes for Firepower Threat Defense 773
About Static and Default Routes 773
Default Route 773
Static Routes 773
Route to null0 Interface to “Black Hole” Unwanted Traffic 774
Route Priorities 774
Transparent Firewall Mode and Bridge Group Routes 774
Static Route Tracking 774
Guidelines for Static and Default Routes 775
Add a Static Route 775

Firepower Management Center Configuration Guide, Version 6.3

xxxii
 Contents

CHAPTER 38 OSPF for Firepower Threat Defense 777

OSPF for Firepower Threat Defense 777
About OSPF 777
OSPF Support for Fast Hello Packets 779
Prerequisites for OSPF Support for Fast Hello Packets 779
OSPF Hello Interval and Dead Interval 779
OSPF Fast Hello Packets 779
Benefits of OSPF Fast Hello Packets 779
Implementation Differences Between OSPFv2 and OSPFv3 780
Guidelines for OSPF 780
Configure OSPFv2 781
Configure OSPF Areas, Ranges, and Virtual Links 781
Configure OSPF Redistribution 784
Configure OSPF Inter-Area Filtering 785
Configure OSPF Filter Rules 786
Configure OSPF Summary Addresses 787
Configure OSPF Interfaces and Neighbors 788
Configure OSPF Advanced Properties 790
Configure OSPFv3 792
Configure OSPFv3 Areas, Route Summaries, and Virtual Links 792
Configure OSPFv3 Redistribution 794
Configure OSPFv3 Summary Prefixes 796
Configure OSPFv3 Interfaces, Authentication, and Neighbors 796
Configure OSPFv3 Advanced Properties 799

CHAPTER 39 BGP for Firepower Threat Defense 803

About BGP 803
Routing Table Changes 803
When to Use BGP 804
BGP Path Selection 804
BGP Multipath 805
Guidelines for BGP 806
Configure BGP 806

Firepower Management Center Configuration Guide, Version 6.3

xxxiii
 Contents

Configure BGP Basic Settings 807

Configure BGP General Settings 809
Configure BGP Neighbor Settings 810
Configure BGP Aggregate Address Settings 813
Configure BGPv4 Filtering Settings 814
Configure BGP Network Settings 815
Configure BGP Redistribution Settings 815
Configure BGP Route Injection Settings 816

CHAPTER 40 RIP for Firepower Threat Defense 819

About RIP 819
Routing Update Process 819
RIP Routing Metric 820
RIP Stability Features 820
RIP Timers 820
Guidelines for RIP 820
Configure RIP 821

CHAPTER 41 Multicast Routing for Firepower Threat Defense 825

About Multicast Routing 825
IGMP Protocol 825
Stub Multicast Routing 826
PIM Multicast Routing 826
PIM Source Specific Multicast Support 827
Multicast Bidirectional PIM 827
PIM Bootstrap Router (BSR) 828
PIM Bootstrap Router (BSR) Terminology 828
Multicast Group Concept 829
Multicast Addresses 829
Clustering 829
Guidelines for Multicast Routing 829
Configure IGMP Features 829
Enable Multicast Routing 830
Configure IGMP Protocol 831

Firepower Management Center Configuration Guide, Version 6.3

xxxiv
 Contents

Configure IGMP Access Groups 832

Configure IGMP Static Groups 833
Configure IGMP Join Groups 833
Configure PIM Features 834
Configure PIM Protocol 834
Configure PIM Neighbor Filters 835
Configure PIM Bidirectional Neighbor Filters 836
Configure PIM Rendezvous Points 837
Configure PIM Route Trees 838
Configure PIM Request Filters 838
Configure the Firepower Threat Defense Device as a Candidate Bootstrap Router 839
Configure Multicast Routes 840
Configure Multicast Boundary Filters 841

PART XII Firepower Threat Defense VPN 843

CHAPTER 42 VPN Overview for Firepower Threat Defense 845

VPN Types 845
VPN Basics 846
Internet Key Exchange (IKE) 846
IPsec 847
VPN Packet Flow 848
VPN Licensing 848
How Secure Should a VPN Connection Be? 848
Complying with Security Certification Requirements 849
Deciding Which Encryption Algorithm to Use 849
Deciding Which Hash Algorithms to Use 850
Deciding Which Diffie-Hellman Modulus Group to Use 850
Deciding Which Authentication Method to Use 851
Pre-shared Keys 851
PKI Infrastructure and Digital Certificates 852

VPN Topology Options 853

Point-to-Point VPN Topology 853
Hub and Spoke VPN Topology 854

Firepower Management Center Configuration Guide, Version 6.3

xxxv
 Contents

Full Mesh VPN Topology 855

Implicit Topologies 855

CHAPTER 43 Site-to-Site VPNs for Firepower Threat Defense 857

About Firepower Threat Defense Site-to-site VPNs 857
Firepower Threat Defense Site-to-site VPN Guidelines and Limitations 858
Managing Firepower Threat Defense Site-to-site VPNs 859
Configuring Firepower Threat Defense Site-to-site VPNs 860
FTD VPN Endpoint Options 861
FTD VPN IKE Options 863
FTD VPN IPsec Options 864
FTD Advanced Site-to-site VPN Deployment Options 866
FTD VPN Advanced IKE Options 866
FTD VPN Advanced IPsec Options 867
FTD Advanced Site-to-site VPN Tunnel Options 867

CHAPTER 44 Remote Access VPNs for Firepower Threat Defense 869

About Remote Access VPNs 869
Remote Access VPN Features 871
Remote Access VPN Guidelines and Limitations 872
Prerequisites for Configuring Remote Access VPN 874
Create a New Remote Access VPN Policy 874
Additional Configuration Requirements for Remote Access VPN 876
Update the Access Control Policy on the Firepower Threat Defense Device 876
(Optional) Configure NAT Exemption 877
Configure DNS 878
Add an AnyConnect Client Profile XML File 878
(Optional) Configure Split Tunneling 879
Managing Remote Access VPNs 880
Configure Connection Profile Settings 880
Configure Multiple Connection Profiles 881
Configure IP Addresses for VPN Clients 882
Remote Access VPN AAA Settings 883
Create or Update Aliases for a Connection Profile 890

Firepower Management Center Configuration Guide, Version 6.3

xxxvi
 Contents

Configure Access Interfaces for Remote Access VPN 891

Remote Access VPN Access Interface Options 893
Configuring Remote Access VPN Advanced Options 894
Cisco AnyConnect Secure Mobility Client Image 894
Remote Access VPN Address Assignment Policy 895
Configure Certificate Maps 896
Configuring Group Policies 897
Configuring IPsec Settings for Remote Access VPNs 897
Dynamic Authorization or RADIUS Change of Authorization (RADIUS CoA) 903
Configuring RADIUS Dynamic Authorization 904
Two-Factor Authentication 905
Configuring RSA Two-Factor Authentication 905
Custom Configurations with Remote Access VPNs 906

Update AnyConnect Images for Remote Access VPN Clients 907

Update the AnyConnect Client Profile for Remote Access VPN Clients 907
Authenticate VPN Users via Client Certificates 908
Configure Remote Access VPN Login via Client Certificate and AAA Server 910
Configure Multiple Connection Profiles 911
Manage Password Changes over VPN Sessions 912
Restrict Connection Profile Selection to a User Group 913
Configure LDAP or Active Directory for Authorization 913
Delegate the Selection of Group Policy or Other Attributes to the Authorization Server 915
Override the Selection of Group Policy or Other Attributes by the Authorization Server 916

Denying VPN Access to a User Group 916

Send Accounting Records to the RADIUS Server 917

CHAPTER 45 VPN Monitoring for Firepower Threat Defense 919

VPN Summary Dashboard 919
Viewing the VPN Summary Dashboard 919
VPN Session and User Information 920
Viewing Remote Access VPN Active Sessions 920
Viewing Remote Access VPN User Activity 920
VPN Health Events 921
Viewing VPN Health Events 921

Firepower Management Center Configuration Guide, Version 6.3

xxxvii
 Contents

CHAPTER 46 VPN Troubleshooting for Firepower Threat Defense 923

System Messages 923
VPN System Logs 923
Viewing VPN System Logs 924
Debug Commands 924
debug aaa 926
debug crypto 926
debug crypto ca 927
debug crypto ikev1 928
debug crypto ikev2 928
debug crypto ipsec 929
debug ldap 929
debug ssl 930
debug webvpn 930

PART XIII Firepower Threat Defense Advanced Settings 933

CHAPTER 47 Threat Defense Service Policies 935

About Firepower Threat Defense Service Policies 935
How Service Policies Relate to FlexConfig and Other Features 936
What Are Connection Settings? 936
Guidelines and Limitations for Service Policies 937
Configure Firepower Threat Defense Service Policies 938
Configure a Service Policy Rule 938
Bypass TCP State Checks for Asynchronous Routing (TCP State Bypass) 941
The Asynchronous Routing Problem 941
Guidelines and Limitations for TCP State Bypass 942
Configure TCP State Bypass 943
Disable TCP Sequence Randomization 945
Examples for Service Policy Rules 946
Protect Servers from a SYN Flood DoS Attack (TCP Intercept) 946
Make the Firepower Threat Defense Device Appear on Traceroutes 949
Monitoring Service Policies 951

Firepower Management Center Configuration Guide, Version 6.3

xxxviii
 Contents

History for Firepower Threat Defense Service Policy 951

CHAPTER 48 FlexConfig Policies for Firepower Threat Defense 953

FlexConfig Policy Overview 953
Recommended Usage for FlexConfig Policies 953
CLI Commands in FlexConfig Objects 954
Determine the ASA Software Version and Current CLI Configuration 954
Blacklisted CLI Commands 955
Template Scripts 957
FlexConfig Variables 957
How to Process Variables 958
How to See What a Variable Will Return for a Device 961
FlexConfig Policy Object Variables 962
FlexConfig System Variables 963
Predefined FlexConfig Objects 964
Predefined Text Objects 968
Guidelines and Limitations for FlexConfig 972
Customizing Device Configuration with FlexConfig Policies 973
Configure FlexConfig Objects 975
Add a Policy Object Variable to a FlexConfig Object 978
Configure Secret Keys 978
Configure FlexConfig Text Objects 979
Configure the FlexConfig Policy 981
Set Target Devices for a FlexConfig Policy 982
Preview the FlexConfig Policy 983
Verify the Deployed Configuration 984
Remove Features Configured Using FlexConfig 986

PART XIV Appliance Platform Settings 989

CHAPTER 49 System Configuration 991

Introduction to System Configuration 992
Navigating the Firepower Management Center System Configuration 992
System Configuration Settings 992

Firepower Management Center Configuration Guide, Version 6.3

xxxix
Contents

Appliance Information 995

Viewing and Modifying the System Information 996
HTTPS Certificates 997
Default HTTPS Server Certificates 997
Custom HTTPS Server Certificates 997
HTTPS Client Certificates 997
Viewing the Current HTTPS Server Certificate 998
Generating an HTTPS Server Certificate Signing Request 998
Importing HTTPS Server Certificates 999
Requiring Valid HTTPS Client Certificates 1001
Renewing the Default HTTPS Server Certificate 1002
External Database Access Settings 1002
Enabling External Access to the Database 1003
Database Event Limits 1004
Configuring Database Event Limits 1004
Database Event Limits 1004
Management Interfaces 1006
About Management Interfaces 1006
Management Interfaces on the Firepower Management Center 1006
Management Interfaces on Managed Devices 1007
Management Interface Support 1007
Network Routes on Management Interfaces 1010
Management and Event Traffic Channel Examples 1010
Configure Management Interfaces 1011
Configure Firepower Management Center Management Interfaces 1012
Configure Classic Device Management Interfaces at the Web Interface 1014
Configure Firepower Threat Defense or Classic Device Management Interfaces at the CLI 1017
System Shut Down and Restart 1022
Shutting Down and Restarting the System 1023
Remote Storage Management 1024
Configuring Local Storage 1024
Configuring NFS for Remote Storage 1024
Configuring SMB for Remote Storage 1025
Configuring SSH for Remote Storage 1026

Firepower Management Center Configuration Guide, Version 6.3

xl
 Contents

Remote Storage Management Advanced Options 1027

Change Reconciliation 1027
Configuring Change Reconciliation 1028
Change Reconciliation Options 1028
Policy Change Comments 1029
Configuring Comments to Track Policy Changes 1029
The Access List 1030
Configuring the Access List for Your System 1030
Audit Logs 1031
Sending Audit Log Messages to the Syslog 1031
Sending Audit Log Messages to an HTTP Server 1033
Audit Log Certificate 1034

How to Securely Stream Audit Logs from the FMC 1035

Obtain a Signed Audit Log Client Certificate for the FMC 1036
Import an Audit Log Client Certificate into the FMC 1037
Require Secure Connections Between Audit Log Server and FMC 1038
View the Audit Log Client Certificate on the FMC 1039

Dashboard Settings 1040

Enabling Custom Analysis Widgets for Dashboards 1040

DNS Cache 1040

Configuring DNS Cache Properties 1040
Email Notifications 1041
Configuring a Mail Relay Host and Notification Address 1041
Language Selection 1042
Specifying a Different Language 1042
Login Banners 1043
Adding a Custom Login Banner 1043
SNMP Polling 1044
Configuring SNMP Polling 1045
Time and Time Synchronization 1046
Synchronize Time Using a Network NTP Server 1046
Synchronize Time Without Access to a Network NTP Server 1047
About Changing Time Synchronization Settings 1048
View Current System Time, Source, and NTP Server Connection Status 1048

Firepower Management Center Configuration Guide, Version 6.3

xli
 Contents

NTP Server Status 1049

Global User Configuration Settings 1050
Set Password Reuse Limit 1050
Track Successful Logins 1051
Enabling Temporary Lockouts 1052
Session Timeouts 1052
Configuring Session Timeouts 1052
Vulnerability Mapping 1053
Mapping Vulnerabilities for Servers 1054
Remote Console Access Management 1054
Configuring Remote Console Settings on the System 1055
Lights-Out Management User Access Configuration 1056
Enabling Lights-Out Management User Access 1056
Serial Over LAN Connection Configuration 1057
Configuring Serial Over LAN with IPMItool 1058
Configuring Serial Over LAN with IPMIutil 1058
Lights-Out Management Overview 1058
Configuring Lights-Out Management with IPMItool 1060
Configuring Lights-Out Management with IPMIutil 1060
REST API Preferences 1061
Enabling REST API Access 1061
VMware Tools and Virtual Systems 1061
Enabling VMware Tools on the Firepower Management Center for VMware 1062
(Optional) Opt Out of Web Analytics Tracking 1062
History for System Configuration 1063

CHAPTER 50 Platform Settings Policies for Managed Devices 1065

Introduction to Platform Settings 1065
Managing Platform Settings Policies 1066
Creating a Platform Settings Policy 1066
Setting Target Devices for a Platform Settings Policy 1067

CHAPTER 51 Platform Settings for Classic Devices 1069

Introduction to Firepower Platform Settings 1069

Firepower Management Center Configuration Guide, Version 6.3

xlii
 Contents

Configuring Firepower Platform Settings 1069

The Access List 1070
Configuring the Access List for Your System 1071
Audit Logs on Classic Devices 1072
Sending Audit Log Messages from Classic Devices to the Syslog 1072
Sending Audit Log Messages to an HTTP Server from a Classic Device 1073
Audit Log Certificate (Classic Devices) 1075
How to Securely Stream Audit Logs from NGIPS Devices 1075
Obtain a Signed Audit Log Client Certificate for a Classic Device 1076
Import an Audit Log Client Certificate into a Classic Device 1077
Require Secure Connections Between Audit Log Server and 7000 and 8000 Series Devices 1078
View the Audit Log Client Certificate on a Classic Device 1079
External Authentication Settings 1080
Enabling External Authentication to Classic Devices 1081
Language Selection 1082
Specifying a Different Language 1082
Login Banners 1083
Adding a Custom Login Banner 1083
Session Timeouts 1084
Configuring Session Timeouts 1084
SNMP Polling 1085
Configuring SNMP Polling 1085
Time and Time Synchronization (Classic Devices) 1087
Synchronizing Time on Classic Devices 1087
View Current System Time, Source, and NTP Server Connection Status for NGIPS Devices 1088
NTP Server Status 1089

CHAPTER 52 Platform Settings for Firepower Threat Defense 1091

Configure ARP Inspection 1091
Configure Banners 1093
Configure DNS 1093
Configure External Authentication for SSH 1095
Configure Fragment Handling 1098
Configure HTTP 1099

Firepower Management Center Configuration Guide, Version 6.3

xliii
 Contents

Configure ICMP Access Rules 1101

Configure SSL Settings 1102
About SSL Settings 1103
Configure Secure Shell 1105
Configure SMTP 1107
Configure SNMP for Threat Defense 1108
Add SNMPv3 Users 1109
Add SNMP Hosts 1110
Configure SNMP Traps 1111
Configure Syslog 1113
About Syslog 1113
Severity Levels 1114
Syslog Message Filtering 1114
Syslog Message Classes 1115
Guidelines for Logging 1118
Configure Syslog Logging for FTD Devices 1119
FTD Platform Settings That Apply to Security Event Syslog Messages 1120
Enable Logging and Configure Basic Settings 1120
Enable Logging Destinations 1122
Send Syslog Messages to an E-mail Address 1123
Create a Custom Event List 1124
Limit the Rate of Syslog Message Generation 1125
Configure Syslog Settings 1126
Configure a Syslog Server 1127
Configure Global Timeouts 1129
Configure NTP Time Synchronization for Threat Defense 1131
History for Firepower Threat Defense Platform Settings 1132

CHAPTER 53 Security Certifications Compliance 1135

Security Certifications Compliance Modes 1135
Security Certifications Compliance Characteristics 1136
Security Certifications Compliance Recommendations 1137
Appliance Hardening 1138
Protecting Your Network 1139

Firepower Management Center Configuration Guide, Version 6.3

xliv
 Contents

Enabling Security Certifications Compliance 1140

PART XV Network Address Translation (NAT) 1143

CHAPTER 54 NAT Policy Management 1145

Managing NAT Policies 1145
Creating NAT Policies 1146
Configuring NAT Policies 1147
Configuring NAT Policy Targets 1148
Copying NAT Policies 1149

CHAPTER 55 NAT for 7000 and 8000 Series Devices 1151

NAT Policy Configuration 1151
NAT Policies Configuration Guidelines 1152
Rule Organization in a NAT Policy 1152
Organizing NAT Rules 1153
NAT Rule Warnings and Errors 1154
Showing and Hiding NAT Rule Warnings 1154
NAT Policy Rules Options 1154
Creating and Editing NAT Rules 1155
NAT Rule Types 1156
NAT Rule Condition Types 1158
NAT Rule Conditions and Condition Mechanics 1159
NAT Rule Conditions 1159
Adding Conditions to NAT Rules 1159
Literal Conditions in NAT Rules 1161
Objects in NAT Rule Conditions 1161
Zone Conditions in NAT Rules 1161
Adding Zone Conditions to NAT Rules 1162
Source Network Conditions in Dynamic NAT Rules 1163
Adding Network Conditions to a Dynamic NAT Rule 1164
Destination Network Conditions in NAT Rules 1165
Adding Destination Network Conditions to NAT Rules 1166
Port Conditions in NAT Rules 1167

Firepower Management Center Configuration Guide, Version 6.3

xlv
 Contents

Adding Port Conditions to NAT Rules 1167

CHAPTER 56 Network Address Translation (NAT) for Firepower Threat Defense 1169
Why Use NAT? 1169
NAT Basics 1170
NAT Terminology 1170
NAT Types 1170
NAT in Routed and Transparent Mode 1171
NAT in Routed Mode 1171
NAT in Transparent Mode or Within a Bridge Group 1172
Auto NAT and Manual NAT 1173
Auto NAT 1173
Manual NAT 1173
Comparing Auto NAT and Manual NAT 1174
NAT Rule Order 1174
NAT Interfaces 1176
Configuring Routing for NAT 1176
Addresses on the Same Network as the Mapped Interface 1176
Addresses on a Unique Network 1177
The Same Address as the Real Address (Identity NAT) 1177
Guidelines for NAT 1177
Firewall Mode Guidelines for NAT 1178
IPv6 NAT Guidelines 1178
IPv6 NAT Recommendations 1178
NAT Support for Inspected Protocols 1179
Additional Guidelines for NAT 1181
Configure NAT for Threat Defense 1182
Customizing NAT Rules for Multiple Devices 1184
Dynamic NAT 1186
About Dynamic NAT 1186
Dynamic NAT Disadvantages and Advantages 1187
Configure Dynamic Auto NAT 1187
Configure Dynamic Manual NAT 1189
Dynamic PAT 1191

Firepower Management Center Configuration Guide, Version 6.3

xlvi
 Contents

About Dynamic PAT 1191

Dynamic PAT Disadvantages and Advantages 1192
PAT Pool Object Guidelines 1192
Configure Dynamic Auto PAT 1193
Configure Dynamic Manual PAT 1195
Static NAT 1198
About Static NAT 1198
Configure Static Auto NAT 1202
Configure Static Manual NAT 1204
Identity NAT 1207
Configure Identity Auto NAT 1208
Configure Identity Manual NAT 1209
NAT Rule Properties for Firepower Threat Defense 1211
Interface Objects NAT Properties 1212
Translation Properties for Auto NAT 1213
Translation Properties for Manual NAT 1214
PAT Pool NAT Properties 1215
Advanced NAT Properties 1216
Translating IPv6 Networks 1217
NAT64/46: Translating IPv6 Addresses to IPv4 1217
NAT64/46 Example: Inside IPv6 Network with Outside IPv4 Internet 1218
NAT66: Translating IPv6 Addresses to Different IPv6 Addresses 1221
NAT66 Example, Static Translation between Networks 1222
NAT66 Example, Simple IPv6 Interface PAT 1224
Monitoring NAT 1226
Examples for NAT 1226
Providing Access to an Inside Web Server (Static Auto NAT) 1226
Dynamic Auto NAT for Inside Hosts and Static NAT for an Outside Web Server 1229
Inside Load Balancer with Multiple Mapped Addresses (Static Auto NAT, One-to-Many) 1232
Single Address for FTP, HTTP, and SMTP (Static Auto NAT-with-Port-Translation) 1235
Different Translation Depending on the Destination (Dynamic Manual PAT) 1240
Different Translation Depending on the Destination Address and Port (Dynamic Manual PAT) 1244
NAT and Site-to-Site VPN 1248
Rewriting DNS Queries and Responses Using NAT 1252

Firepower Management Center Configuration Guide, Version 6.3

xlvii
 Contents

DNS64 Reply Modification 1253

DNS Reply Modification, DNS Server on Outside 1259
DNS Reply Modification, DNS Server on Host Network 1262
History for FTD NAT 1265

PART XVI 7000 and 8000 Series Advanced Deployment Options 1267

CHAPTER 57 Setting Up Virtual Switches 1269

Virtual Switches 1269
Switched Interface Configuration 1269
Switched Interface Configuration Notes 1270
Configuring Physical Switched Interfaces 1271
Adding Logical Switched Interfaces 1272
Deleting Logical Switched Interfaces 1273
Virtual Switch Configuration 1274
Virtual Switch Configuration Notes 1274
Adding Virtual Switches 1275
Advanced Virtual Switch Settings 1275
Configuring Advanced Virtual Switch Settings 1276
Deleting Virtual Switches 1277

CHAPTER 58 Setting Up Virtual Routers 1279

Virtual Routers 1279
Routed Interfaces 1280
Configuring Physical Routed Interfaces 1281
Adding Logical Routed Interfaces 1283
Deleting Logical Routed Interfaces 1285
Configuring SFRP 1286
Virtual Router Configuration 1287
Adding Virtual Routers 1288
DHCP Relay 1289
Setting Up DHCPv4 Relay 1289
Setting Up DHCPv6 Relay 1290
Static Routes 1291

Firepower Management Center Configuration Guide, Version 6.3

xlviii
 Contents

Viewing the Static Routes Table 1292

Adding Static Routes 1292
Dynamic Routing 1293
RIP Configuration 1293
Adding Interfaces for RIP Configuration 1293
Configuring Authentication Settings for RIP Configuration 1294
Configuring Advanced Settings for RIP Configuration 1295
Adding Import Filters for RIP Configuration 1296
Adding Export Filters for RIP Configuration 1297
OSPF Configuration 1298
OSPF Routing Areas 1298
OSPF Area Interfaces 1299
Adding OSPF Area Interfaces 1301
Adding OSPF Area Vlinks 1302
Adding Import Filters for OSPF Configuration 1303
Adding Export Filters for OSPF Configuration 1304
Virtual Router Filters 1305
Viewing Virtual Router Filters 1306
Setting Up Virtual Router Filters 1307
Adding Virtual Router Authentication Profiles 1308
Viewing Virtual Router Statistics 1309
Deleting Virtual Routers 1309

CHAPTER 59 Aggregate Interfaces and LACP 1311

About Aggregate Interfaces 1311
LAG Configuration 1312
Aggregate Switched Interfaces 1312
Aggregate Routed Interfaces 1313
Logical Aggregate Interfaces 1313
Load-Balancing Algorithms 1314
Link Selection Policies 1315
Link Aggregation Control Protocol (LACP) 1316
LACP 1316
Adding Aggregate Switched Interfaces 1317

Firepower Management Center Configuration Guide, Version 6.3

xlix
 Contents

Adding Aggregate Routed Interfaces 1319

Adding Logical Aggregate Interfaces 1322
Viewing Aggregate Interface Statistics 1323
Deleting Aggregate Interfaces 1323

CHAPTER 60 Hybrid Interfaces 1325

About Hybrid Interfaces 1325
Logical Hybrid Interfaces 1325
Adding Logical Hybrid Interfaces 1326
Deleting Logical Hybrid Interfaces 1328

CHAPTER 61 Gateway VPNs 1329

Gateway VPN Basics 1329
IPsec 1329
IKE 1330
VPN Deployments 1330
Point-to-Point VPN Deployments 1330
Star VPN Deployments 1331
Mesh VPN Deployments 1332
VPN Deployment Management 1332
VPN Deployment Options 1333
Point-to-Point VPN Deployment Options 1333
Star VPN Deployment Options 1334
Mesh VPN Deployment Options 1336
Advanced VPN Deployment Options 1337
Managing VPN Deployments 1338
Configuring Point-to-Point VPN Deployments 1339
Configuring Star VPN Deployments 1339
Configuring Mesh VPN Deployments 1340
Configuring Advanced VPN Deployment Settings 1341
Editing VPN Deployments 1342
VPN Deployment Status 1343
Viewing VPN Status 1343
VPN Statistics and Logs 1344

Firepower Management Center Configuration Guide, Version 6.3

l
 Contents

Viewing VPN Statistics and Logs 1345

PART XVII Access Control 1347

CHAPTER 62 Getting Started with Access Control Policies 1349

Introduction to Access Control 1349
Access Control Policy Components 1350
Access Control Policy Default Action 1351
Access Control Policy Inheritance 1353
Managing Access Control Policies 1354
Creating a Basic Access Control Policy 1355
Editing an Access Control Policy 1356
Managing Access Control Policy Inheritance 1358
Choosing a Base Access Control Policy 1359
Inheriting Access Control Policy Settings from the Base Policy 1359
Locking Settings in Descendant Access Control Policies 1360
Requiring an Access Control Policy in a Domain 1360
Setting Target Devices for an Access Control Policy 1361
Logging Settings 1362
Access Control Policy Advanced Settings 1362
Associating Other Policies with Access Control 1365

CHAPTER 63 Access Control Rules 1367

Introduction to Access Control Rules 1367
Recommendations for Application Control 1369
Access Control Rule Management 1370
Access Control Rule Components 1371
Access Control Rule Order 1372
Adding an Access Control Rule Category 1373
Creating and Editing Access Control Rules 1374
Enabling and Disabling Access Control Rules 1375
Positioning an Access Control Rule 1376
Access Control Rule Actions 1376
Access Control Rule Monitor Action 1377

Firepower Management Center Configuration Guide, Version 6.3

li
 Contents

Access Control Rule Trust Action 1377

Access Control Rule Blocking Actions 1377
Access Control Rule Interactive Blocking Actions 1378
Access Control Rule Allow Action 1379
Access Control Rule Comments 1379
Adding Comments to an Access Control Rule 1380

CHAPTER 64 Access Control Using Intrusion and File Policies 1381

About Deep Inspection 1381
Access Control Traffic Handling 1382
File and Intrusion Inspection Order 1383
Access Control Rule Configuration to Perform Malware Protection 1384
Configuring an Access Control Rule to Perform Malware Protection 1385
Access Control Rule Configuration to Perform Intrusion Prevention 1386
Access Control Rule Configuration and Intrusion Policies 1387
Configuring an Access Control Rule to Perform Intrusion Prevention 1387

CHAPTER 65 URL Filtering 1389

URL Filtering Overview 1389
About URL Filtering with Category and Reputation 1389
URL Filtering Data from the Cisco Cloud 1390

Guidelines and Limitations for URL Filtering 1390

Filtering HTTPS Traffic 1392
How to Configure URL Filtering with Category and Reputation 1393
Enable URL Filtering Using Category and Reputation 1394
URL Filtering Options 1394
Configuring URL Conditions 1395
Rules with URL Conditions 1397
URL Rule Order 1398
Configure URL Filtering Health Monitors 1398
Manual URL Filtering 1398
Troubleshoot URL Filtering 1399
History for URL Filtering 1400

Firepower Management Center Configuration Guide, Version 6.3

lii
 Contents

CHAPTER 66 HTTP Response Pages and Interactive Blocking 1401

About HTTP Response Pages 1401
Limitations to HTTP Response Pages 1401
Choosing HTTP Response Pages 1402
Interactive Blocking with HTTP Response Pages 1403
Configuring Interactive Blocking 1403
Setting the User Bypass Timeout for a Blocked Website 1404

CHAPTER 67 Security Intelligence Blacklisting 1405

About Security Intelligence 1405
Requirements for Security Intelligence 1406
Guidelines for Security Intelligence 1406
Configure Security Intelligence 1407
Security Intelligence Options 1409
Troubleshooting Security Intelligence 1410
Troubleshooting Memory Use 1410

CHAPTER 68 DNS Policies 1411

DNS Policy Overview 1411
DNS Policy Components 1411
Creating Basic DNS Policies 1413
Editing DNS Policies 1413
Managing DNS Policies 1414
DNS Rules 1415
Creating and Editing DNS Rules 1415
DNS Rule Management 1416
Enabling and Disabling DNS Rules 1416
DNS Rule Order Evaluation 1417
DNS Rule Actions 1417
DNS Rule Conditions 1419
Controlling Traffic Based on DNS and Security Zone 1419
Controlling Traffic Based on DNS and Network 1420
Controlling Traffic Based on DNS and VLAN 1421

Firepower Management Center Configuration Guide, Version 6.3

liii
 Contents

Controlling Traffic Based on DNS List, Feed, or Category 1422

DNS Policy Deploy 1422

CHAPTER 69 Prefiltering and Prefilter Policies 1423

About Prefiltering 1423
Prefiltering vs Access Control 1423
Passthrough Tunnels and Access Control 1425
Guidelines and Limitations for Prefiltering 1426
Configure Prefiltering 1426
About Prefilter Policies 1428
Tunnel vs Prefilter Rules 1428
Tunnel and Prefilter Rule Components 1429
Tunnel Zones and Prefiltering 1431
Using Tunnel Zones 1431
Creating Tunnel Zones 1434

CHAPTER 70 Intelligent Application Bypass 1435

Introduction to IAB 1435
IAB Options 1436
Configuring IAB 1438
IAB Logging and Analysis 1439

CHAPTER 71 Access Control Using Content Restriction 1443

About Content Restriction 1443
Using Access Control Rules to Enforce Content Restriction 1444
Safe Search Options for Access Control Rules 1446
YouTube EDU Options for Access Control Rules 1446
Using a DNS Sinkhole to Enforce Content Restriction 1446

PART XVIII Encrypted Traffic Handling 1449

CHAPTER 72 Understanding Traffic Decryption 1451

About Traffic Decryption 1451
TLS/SSL Handshake Processing 1452

Firepower Management Center Configuration Guide, Version 6.3

liv
 Contents

ClientHello Message Handling 1453

ServerHello and Server Certificate Message Handling 1455
TLS/SSL Hardware Acceleration 1456
TLS/SSL Hardware Acceleration Guidelines and Limitations 1457
View the Status of TLS/SSL Hardware Acceleration 1459
TLS/SSL Inspection Requirements 1459
TLS/SSL Rules Configuration Prerequisite Information 1460
TLS/SSL Inspection Appliance Deployment Scenarios 1460
Traffic Decryption in a Passive Deployment 1461
Encrypted Traffic Monitoring in a Passive Deployment 1462
Undecrypted Encrypted Traffic in a Passive Deployment 1463
Encrypted Traffic Inspection with a Private Key in a Passive Deployment 1463
Traffic Decryption in an Inline Deployment 1465
Encrypted Traffic Monitoring in an Inline Deployment 1467
Undecrypted Encrypted Traffic in an Inline Deployment 1467
Encrypted Traffic Blocking in an Inline Deployment 1468
Encrypted Traffic Inspection with a Private Key in an Inline Deployment 1469
Encrypted Traffic Inspection with a Re-signed Certificate in an Inline Deployment 1471
History for TLS/SSL 1473

CHAPTER 73 Start Creating SSL Policies 1475

SSL Policies Overview 1475
SSL Policy Default Actions 1476
Default Handling Options for Undecryptable Traffic 1477
Manage SSL Policies 1478
Create Basic SSL Policies 1479
Set Default Handling for Undecryptable Traffic 1480
Editing an SSL Policy 1480

CHAPTER 74 Get Started with TLS/SSL Rules 1483

TLS/SSL Rules Overview 1483
TLS/SSL Rule Guidelines and Limitations 1483
Encrypted Traffic Inspection Configuration 1485
Creating and Modifying TLS/SSL Rules 1486

Firepower Management Center Configuration Guide, Version 6.3

lv
 Contents

Adding a TLS/SSL Rule to a Rule Category 1487

Positioning a TLS/SSL Rule by Number 1487
TLS/SSL Rule Search 1488
Searching TLS/SSL Rules 1488
Enabling and Disabling TLS/SSL Rules 1489
Moving a TLS/SSL Rule 1489
Adding a New TLS/SSL Rule Category 1490
TLS/SSL Rule Conditions 1491
TLS/SSL Rule Condition Types 1491
TLS/SSL Rule Actions 1493
TLS/SSL Rule Monitor Action 1493
TLS/SSL Rule Do Not Decrypt Action 1493
TLS/SSL Rule Blocking Actions 1493
TLS/SSL Rule Decrypt Actions 1494
TLS/SSL Rule Decryption Mechanism and Guidelines 1494
Configuring TLS/SSL Rule Actions 1496
Configuring a Decrypt - Resign Action 1497
Configuring a Decrypt - Known Key Action 1498
TLS/SSL Rules Management 1498

CHAPTER 75 Decryption Tuning Using TLS/SSL Rules 1499

TLS/SSL Rule Conditions Overview 1499
Network-Based TLS/SSL Rule Conditions 1500
Network Zone TLS/SSL Rule Conditions 1500
Controlling Encrypted Traffic by Network Zone 1501
Network or Geolocation TLS/SSL Rule Conditions 1502
Controlling Encrypted Traffic by Network or Geolocation 1502
VLAN TLS/SSL Rule Conditions 1504
Controlling Encrypted VLAN Traffic 1504
Port TLS/SSL Rule Conditions 1505
Controlling Encrypted Traffic by Port 1506
User-Based TLS/SSL Rule Conditions 1507
Controlling Encrypted Traffic Based on User 1507
Reputation-Based TLS/SSL Rule Conditions 1507

Firepower Management Center Configuration Guide, Version 6.3

lvi
 Contents

Selected Applications and Filters in TLS/SSL Rules 1508

Application Filters in TLS/SSL Rules 1508
Available Applications in TLS/SSL Rules 1509
Application-Based TLS/SSL Rule Condition Requirements 1511
Adding an Application Condition to a TLS/SSL Rule 1511
Limitations to Encrypted Application Control 1512
Reputation-Based URL Blocking in Encrypted Traffic 1513
Block Encrypted Traffic Based on URL Reputation 1513
Server Certificate-Based TLS/SSL Rule Conditions 1514
Certificate Distinguished Name TLS/SSL Rule Conditions 1515
Controlling Encrypted Traffic by Certificate Distinguished Name 1516
Certificate TLS/SSL Rule Conditions 1517
Controlling Encrypted Traffic by Certificate 1518
Certificate Status TLS/SSL Rule Conditions 1519
Trusting External Certificate Authorities 1522
Matching Traffic on Certificate Status 1524
Cipher Suite TLS/SSL Rule Conditions 1525
Controlling Encrypted Traffic by Cipher Suite 1528
Encryption Protocol Version TLS/SSL Rule Conditions 1528
Controlling Traffic by Encryption Protocol Version 1529

CHAPTER 76 Monitor SSL Hardware Acceleration 1531

Informational Counters 1531
Alert Counters 1532
Error Counters 1532
Fatal Counters 1533

CHAPTER 77 Troubleshoot TLS/SSL Rules 1535

About TLS/SSL Oversubscription 1535
Troubleshoot TLS/SSL Oversubscription 1536
About TLS Heartbeat 1538
Troubleshoot TLS Heartbeat 1538
About TLS/SSL Pinning 1539
Troubleshoot TLS/SSL Pinning 1540

Firepower Management Center Configuration Guide, Version 6.3

lvii
 Contents

Verify TLS/SSL Cipher Suites 1542

PART XIX Advanced Malware Protection (AMP) and File Control 1545

CHAPTER 78 File Policies and Advanced Malware Protection 1547

About File Policies and Advanced Malware Protection 1547
Malware Protection Methods 1547
Spero Analysis 1548
AMP Cloud Lookup 1548
Local Malware Analysis 1548
Cached Disposition Longevity 1548
Dynamic Analysis 1549
Which Files Are Eligible for Dynamic Analysis? 1549
Block All Files by Type 1550
Comparison of Malware Protection Methods 1550
How to Configure Malware Protection 1551
Cloud Connections for Malware Protection 1553
AMP Cloud Connection Configurations 1554
Configure Communications with the AMP Cloud 1555
Requirements and Guidelines for AMP Cloud Connections 1556
Cisco AMP Private Cloud 1556
Managing Connections to the AMP Cloud (Public or Private) 1558

Dynamic Analysis Connections 1559

Requirements for Dynamic Analysis 1559
Viewing the Default Dynamic Analysis Connection 1559
Dynamic Analysis On-Premises Appliance (Cisco Threat Grid) 1560

Enabling Access to Dynamic Analysis Results in the Public Cloud 1561

Maintain Your System: Update File Types Eligible for Dynamic Analysis 1562
Cisco Security Intelligence Clouds 1562
File Policies and File Rules 1563
File Policy and File Rule Guidelines and Limitations 1563
File Rule Configuration Guidelines and Limitations 1563
File Detection Notes and Limitations 1563
File Blocking Notes and Limitations 1564

Firepower Management Center Configuration Guide, Version 6.3

lviii
 Contents

File Policy General Guidelines and Limitations 1564

File Policies 1565
Managing File Policies 1566
Creating a File Policy 1567
Advanced and Archive File Inspection Options 1567
Editing a File Policy 1570
File Rules 1571
File Rule Components 1572
File Rule Actions 1573
Creating File Rules 1576
Retrospective Disposition Changes 1577
(Optional) Malware Protection with AMP for Endpoints 1577
Comparison of Malware Protection: Firepower vs. AMP for Endpoints 1578
About Integrating Firepower with AMP for Endpoints 1579
Benefits of Integrating Firepower and AMP for Endpoints 1579
AMP for Endpoints and AMP Private Cloud 1580
Integrate Firepower and AMP for Endpoints 1580
History for the File and Malware Chapter 1582

CHAPTER 79 File and Malware Inspection Performance and Storage Tuning 1583
File and Malware Inspection Performance and Storage Options 1583
Tuning File and Malware Inspection Performance and Storage 1585

PART XX TID Intelligence and Threat Analysis 1587

CHAPTER 80 Cisco Threat Intelligence Director (TID) 1589

Cisco Threat Intelligence Director (TID) Overview 1589
TID and Security Intelligence 1591
Performance Impact of Threat Intelligence Director 1591
Cisco Threat Intelligence Director (TID) and High Availability Configurations 1592
Requirements for Threat Intelligence Director 1592
Platform, Element, and License Requirements 1592
Source Requirements 1592
Source Content Limitations 1593

Firepower Management Center Configuration Guide, Version 6.3

lix
Contents

How To Set Up Cisco Threat Intelligence Director (TID) 1594

Configure Policies to Support TID 1595
Options for Ingesting Data Sources 1596
Fetch TAXII Feeds to Use as Sources 1596
Fetch Sources from a URL 1598
Upload a Local File to Use as a Source 1599
Configure TLS/SSL Settings for a TID Source 1600
User Roles with TID Access 1602
About Backing Up and Restoring TID Data 1602
Analyze TID Incident and Observation Data 1602
Observation and Incident Generation 1602
View and Manage Incidents 1604
Incident Summary Information 1605
Incident Details 1606
View Events for a TID Observation 1609
TID Observations in Firepower Management Center Events 1610
TID-Firepower Management Center Action Prioritization 1610
Factors That Affect the Action Taken 1613
View and Change Cisco Threat Intelligence Director (TID) Configurations 1613
View TID Status of Elements (Managed Devices) 1613
View and Manage Sources 1614
Source Summary Information 1615
Source Status Details 1616
View and Manage Indicators 1617
Indicator Summary Information 1618
Indicator Details 1619
View and Manage Observables 1620
Observable Summary Information 1620
Filter TID Data in Table Views 1621
Inheritance in TID Configurations 1622
Inheritance of TID Settings from Multiple Parents 1622
About Overriding Inherited TID Settings 1623
Edit TID Actions at the Source, Indicator, or Observable Level 1623
About Pausing Publishing 1624

Firepower Management Center Configuration Guide, Version 6.3

lx
 Contents

Pause TID and Purge TID Data from Elements 1625

Pause or Publish TID Data at the Source, Indicator, or Observable Level 1626
Modify the Observable Publication Frequency 1627
About Whitelisting TID Observables 1627
Whitelist TID Observables 1628
View a STIX Source File 1628
Troubleshoot Cisco Threat Intelligence Director (TID) 1628
History for Cisco Threat Intelligence Director (TID) 1631

PART XXI Intrusion Detection and Prevention 1633

CHAPTER 81 An Overview of Network Analysis and Intrusion Policies 1635

Network Analysis and Intrusion Policy Basics 1635
How Policies Examine Traffic For Intrusions 1636
Decoding, Normalizing, and Preprocessing: Network Analysis Policies 1637
Access Control Rules: Intrusion Policy Selection 1638
Intrusion Inspection: Intrusion Policies, Rules, and Variable Sets 1638
Intrusion Event Generation 1640
System-Provided and Custom Network Analysis and Intrusion Policies 1640
System-Provided Network Analysis and Intrusion Policies 1641
Benefits of Custom Network Analysis and Intrusion Policies 1643
Benefits of Custom Network Analysis Policies 1643
Benefits of Custom Intrusion Policies 1644
Limitations of Custom Policies 1645
The Navigation Panel: Network Analysis and Intrusion Policies 1647
Conflicts and Changes: Network Analysis and Intrusion Policies 1648
Exiting a Network Analysis or Intrusion Policy 1649

CHAPTER 82 Layers in Intrusion and Network Analysis Policies 1651

Layer Basics 1651
The Layer Stack 1651
The Base Layer 1652
System-Provided Base Policies 1652
Custom Base Policies 1653

Firepower Management Center Configuration Guide, Version 6.3

lxi
 Contents

The Effect of Rule Updates on Base Policies 1653

Changing the Base Policy 1654
The Firepower Recommendations Layer 1655
Layer Management 1656
Shared Layers 1657
Managing Layers 1658
Navigating Layers 1659
Intrusion Rules in Layers 1659
Configuring Intrusion Rules in Layers 1661
Removing Rule Settings from Multiple Layers 1661
Accepting Rule Changes from a Custom Base Policy 1663
Preprocessors and Advanced Settings in Layers 1664
Configuring Preprocessors and Advanced Settings in Layers 1664

CHAPTER 83 Getting Started with Intrusion Policies 1667

Intrusion Policy Basics 1667
Managing Intrusion Policies 1668
Custom Intrusion Policy Creation 1669
Creating a Custom Intrusion Policy 1670
Editing Intrusion Policies 1670
Intrusion Policy Changes 1671
Drop Behavior in an Inline Deployment 1672
Setting Drop Behavior in an Inline Deployment 1672
Drop Behavior in a Dual System Deployment 1673
Intrusion Policy Advanced Settings 1673
Optimizing Performance for Intrusion Detection and Prevention 1674

CHAPTER 84 Tuning Intrusion Policies Using Rules 1675

Intrusion Rule Tuning Basics 1675
Intrusion Rule Types 1675
Viewing Intrusion Rules in an Intrusion Policy 1676
Intrusion Rules Page Columns 1677
Intrusion Rule Details 1678
Viewing Intrusion Rule Details 1679

Firepower Management Center Configuration Guide, Version 6.3

lxii
 Contents

Setting a Threshold for an Intrusion Rule 1679

Setting Suppression for an Intrusion Rule 1680
Setting a Dynamic Rule State from the Rule Details Page 1681
Setting an SNMP Alert for an Intrusion Rule 1682
Adding a Comment to an Intrusion Rule 1682
Intrusion Rule Filters in an Intrusion Policy 1683
Intrusion Rule Filters Notes 1683
Intrusion Policy Rule Filters Construction Guidelines 1683
Intrusion Rule Configuration Filters 1686
Intrusion Rule Content Filters 1687
Intrusion Rule Categories 1688
Intrusion Rule Filter Components 1688
Intrusion Rule Filter Usage 1689
Setting a Rule Filter in an Intrusion Policy 1689
Intrusion Rule States 1690
Intrusion Rule State Options 1690
Setting Intrusion Rule States 1691
Intrusion Event Notification Filters in an Intrusion Policy 1692
Intrusion Event Thresholds 1692
Intrusion Event Thresholds Configuration 1692
Adding and Modifying Intrusion Event Thresholds 1694
Viewing and Deleting Intrusion Event Thresholds 1695
Intrusion Policy Suppression Configuration 1696
Intrusion Policy Suppression Types 1696
Suppressing Intrusion Events for a Specific Rule 1697
Viewing and Deleting Suppression Conditions 1698
Dynamic Intrusion Rule States 1699
Dynamic Intrusion Rule State Configuration 1699
Setting a Dynamic Rule State from the Rules Page 1700
Adding Intrusion Rule Comments 1702

CHAPTER 85 Tailoring Intrusion Protection to Your Network Assets 1703

About Firepower Recommended Rules 1703
Default Settings for Firepower Recommendations 1704

Firepower Management Center Configuration Guide, Version 6.3

lxiii
 Contents

Advanced Settings for Firepower Recommendations 1705

Generating and Applying Firepower Recommendations 1706

CHAPTER 86 Sensitive Data Detection 1709

Sensitive Data Detection Basics 1709
Global Sensitive Data Detection Options 1710
Individual Sensitive Data Type Options 1711
System-Provided Sensitive Data Types 1712
Configuring Sensitive Data Detection 1713
Monitored Application Protocols and Sensitive Data 1714
Selecting Application Protocols to Monitor 1715
Special Case: Sensitive Data Detection in FTP Traffic 1716
Custom Sensitive Data Types 1716
Data Patterns in Custom Sensitive Data Types 1717
Configuring Custom Sensitive Data Types 1719
Editing Custom Sensitive Data Types 1720

CHAPTER 87 Globally Limiting Intrusion Event Logging 1723

Global Rule Thresholding Basics 1723
Global Rule Thresholding Options 1724
Configuring Global Thresholds 1726
Disabling the Global Threshold 1727

CHAPTER 88 The Intrusion Rules Editor 1729

An Introduction to Intrusion Rule Editing 1729
Rule Anatomy 1730
The Intrusion Rule Header 1731
Intrusion Rule Header Action 1731
Intrusion Rule Header Protocol 1732
Intrusion Rule Header Direction 1732
Intrusion Rule Header Source and Destination IP Addresses 1733
Intrusion Rule Header Source and Destination Ports 1735
Intrusion Event Details 1736
Adding a Custom Classification 1740

Firepower Management Center Configuration Guide, Version 6.3

lxiv
 Contents

Defining an Event Priority 1741

Defining an Event Reference 1741
Custom Rule Creation 1742
Writing New Rules 1743
Modifying Existing Rules 1744
Viewing Rule Documentation 1745
Adding Comments to Intrusion Rules 1746
Deleting Custom Rules 1747
Searching for Rules 1748
Search Criteria for Intrusion Rules 1748
Rule Filtering on the Intrusion Rules Editor Page 1749
Filtering Guidelines 1749
Keyword Filtering 1750
Character String Filtering 1751
Combination Keyword and Character String Filtering 1751
Filtering Rules 1752
Keywords and Arguments in Intrusion Rules 1752
The content and protected_content Keywords 1753
Basic content and protected_content Keyword Arguments 1754
content and protected_content Keyword Search Locations 1755
Overview: HTTP content and protected_content Keyword Arguments 1758
Overview: content Keyword Fast Pattern Matcher 1761
The replace Keyword 1764
The byte_jump Keyword 1765
The byte_test Keyword 1767
The byte_extract Keyword 1769
The byte_math Keyword 1772
Overview: The pcre Keyword 1774
pcre Syntax 1775
pcre Modifier Options 1777
pcre Example Keyword Values 1780
The metadata Keyword 1782
Service Metadata 1783
Metadata Search Guidelines 1788

Firepower Management Center Configuration Guide, Version 6.3

lxv
Contents

IP Header Values 1789

ICMP Header Values 1791
TCP Header Values and Stream Size 1792
The stream_reassembly Keyword 1796
SSL Keywords 1796
The appid Keyword 1798
Application Layer Protocol Values 1799
The RPC Keyword 1799
The ASN.1 Keyword 1799
The urilen Keyword 1800
DCE/RPC Keywords 1801
SIP Keywords 1804
GTP Keywords 1806
SCADA Keywords 1818
Modbus Keywords 1818
DNP3 Keywords 1819
CIP and ENIP Keywords 1822
Packet Characteristics 1822
Active Response Keywords 1824
The resp Keyword 1825
The react Keyword 1826
The config response Command 1827
The detection_filter Keyword 1827
The tag Keyword 1829
The flowbits Keyword 1830
flowbits Keyword Options 1830
Guidelines for Using the flowbits Keyword 1831
flowbits Keyword Examples 1832
The http_encode Keyword 1837
http_encode Keyword Syntax 1838
http_encode Keyword example: Using Two http_endcode Keywords to Search for Two Encodings
1838

Overview: The file_type and file_group Keywords 1838

The file_type and file_group Keywords 1839

Firepower Management Center Configuration Guide, Version 6.3

lxvi
 Contents

The file_data Keyword 1840

The pkt_data Keyword 1841
The base64_decode and base64_data Keywords 1841

CHAPTER 89 Intrusion Prevention Performance Tuning 1843

About Intrusion Prevention Performance Tuning 1843
Limiting Pattern Matching for Intrusions 1844
Regular Expression Limits Overrides for Intrusion Rules 1844
Overriding Regular Expression Limits for Intrusion Rules 1845
Per Packet Intrusion Event Generation Limits 1846
Limiting Intrusion Events Generated Per Packet 1847
Packet and Intrusion Rule Latency Threshold Configuration 1847
Latency-Based Performance Settings 1847
Packet Latency Thresholding 1848
Packet Latency Thresholding Notes 1849
Configuring Packet Latency Thresholding 1849
Rule Latency Thresholding 1850
Rule Latency Thresholding Notes 1852
Configuring Rule Latency Thresholding 1852
Intrusion Performance Statistic Logging Configuration 1853
Configuring Intrusion Performance Statistic Logging 1854

PART XXII Advanced Network Analysis and Preprocessing 1855

CHAPTER 90 Advanced Access Control Settings for Network Analysis and Intrusion Policies 1857
About Advanced Access Control Settings for Network Analysis and Intrusion Policies 1857
The Default Intrusion Policy 1857
Setting the Default Intrusion Policy 1858
Advanced Settings for Network Analysis Policies 1859
Setting the Default Network Analysis Policy 1860
Network Analysis Rules 1860
Configuring Network Analysis Rules 1861
Managing Network Analysis Rules 1862

Firepower Management Center Configuration Guide, Version 6.3

lxvii
 Contents

CHAPTER 91 Getting Started with Network Analysis Policies 1863

Network Analysis Policy Basics 1863
Managing Network Analysis Policies 1863
Custom Network Analysis Policy Creation 1864
Creating a Custom Network Analysis Policy 1865
Network Analysis Policy Management 1866
Network Analysis Policy Settings and Cached Changes 1866
Editing Network Analysis Policies 1867
Preprocessor Configuration in a Network Analysis Policy 1868
Preprocessor Traffic Modification in Inline Deployments 1869
Preprocessor Configuration in a Network Analysis Policy Notes 1869

CHAPTER 92 Application Layer Preprocessors 1871

Introduction to Application Layer Preprocessors 1871
The DCE/RPC Preprocessor 1871
Connectionless and Connection-Oriented DCE/RPC Traffic 1872
DCE/RPC Target-Based Policies 1873
RPC over HTTP Transport 1874
DCE/RPC Global Options 1875
DCE/RPC Target-Based Policy Options 1876
Traffic-Associated DCE/RPC Rules 1880
Configuring the DCE/RPC Preprocessor 1881
The DNS Preprocessor 1882
DNS Preprocessor Options 1884
Configuring the DNS Preprocessor 1885
The FTP/Telnet Decoder 1886
Global FTP and Telnet Options 1886
Telnet Options 1887
Server-Level FTP Options 1887
FTP Command Validation Statements 1890
Client-Level FTP Options 1891
Configuring the FTP/Telnet Decoder 1892
The HTTP Inspect Preprocessor 1893

Firepower Management Center Configuration Guide, Version 6.3

lxviii
 Contents

Global HTTP Normalization Options 1894

Server-Level HTTP Normalization Options 1895
Server-Level HTTP Normalization Encoding Options 1903
Configuring The HTTP Inspect Preprocessor 1906
Additional HTTP Inspect Preprocessor Rules 1908
The Sun RPC Preprocessor 1908
Sun RPC Preprocessor Options 1909
Configuring the Sun RPC Preprocessor 1909
The SIP Preprocessor 1910
SIP Preprocessor Options 1911
Configuring the SIP Preprocessor 1913
Additional SIP Preprocessor Rules 1914
The GTP Preprocessor 1915
GTP Preprocessor Rules 1915
Configuring the GTP Preprocessor 1915
The IMAP Preprocessor 1916
IMAP Preprocessor Options 1917
Configuring the IMAP Preprocessor 1918
Additional IMAP Preprocessor Rules 1919
The POP Preprocessor 1919
POP Preprocessor Options 1919
Configuring the POP Preprocessor 1921
Additional POP Preprocessor Rules 1921
The SMTP Preprocessor 1922
SMTP Preprocessor Options 1922
Configuring SMTP Decoding 1926
The SSH Preprocessor 1927
SSH Preprocessor Options 1928
Configuring the SSH Preprocessor 1930
The SSL Preprocessor 1931
How SSL Preprocessing Works 1932
SSL Preprocessor Options 1933
Configuring the SSL Preprocessor 1934
SSL Preprocessor Rules 1935

Firepower Management Center Configuration Guide, Version 6.3

lxix
 Contents

CHAPTER 93 SCADA Preprocessors 1937

Introduction to SCADA Preprocessors 1937
The Modbus Preprocessor 1937
Modbus Preprocessor Ports Option 1938
Configuring the Modbus Preprocessor 1938
Modbus Preprocessor Rules 1939
The DNP3 Preprocessor 1939
DNP3 Preprocessor Options 1940
Configuring the DNP3 Preprocessor 1940
DNP3 Preprocessor Rules 1941
The CIP Preprocessor 1942
CIP Preprocessor Options 1942
CIP Events 1942
CIP Preprocessor Rules 1943
Guidelines for Configuring the CIP Preprocessor 1943
Configuring the CIP Preprocessor 1944

CHAPTER 94 Transport & Network Layer Preprocessors 1947

Introduction to Transport and Network Layer Preprocessors 1947
Advanced Transport/Network Preprocessor Settings 1947
Ignored VLAN Headers 1947
Active Responses with Intrusion Drop Rules 1948
Advanced Transport/Network Preprocessor Options 1948
Configuring Advanced Transport/Network Preprocessor Settings 1950
Checksum Verification 1950
Checksum Verification Options 1950
Verifying Checksums 1951
The Inline Normalization Preprocessor 1952
Inline Normalization Options 1952
Configuring Inline Normalization 1957
The IP Defragmentation Preprocessor 1958
IP Fragmentation Exploits 1959
Target-Based Defragmentation Policies 1959

Firepower Management Center Configuration Guide, Version 6.3

lxx
 Contents

IP Defragmentation Options 1959

Configuring IP Defragmentation 1962
The Packet Decoder 1963
Packet Decoder Options 1963
Configuring Packet Decoding 1967
TCP Stream Preprocessing 1968
State-Related TCP Exploits 1968
Target-Based TCP Policies 1968
TCP Stream Reassembly 1969
TCP Stream Preprocessing Options 1970
Configuring TCP Stream Preprocessing 1977
UDP Stream Preprocessing 1978
UDP Stream Preprocessing Options 1979
Configuring UDP Stream Preprocessing 1979

CHAPTER 95 Detecting Specific Threats 1981

Introduction to Specific Threat Detection 1981
Back Orifice Detection 1981
Back Orifice Detection Preprocessor 1981
Detecting Back Orifice 1982
Portscan Detection 1983
Portscan Types, Protocols, and Filtered Sensitivity Levels 1983
Portscan Event Generation 1985
Portscan Event Packet View 1987
Configuring Portscan Detection 1988
Rate-Based Attack Prevention 1990
Rate-Based Attack Prevention Examples 1991
detection_filter Keyword Example 1991
Dynamic Rule State Thresholding or Suppression Example 1992
Policy-Wide Rate-Based Detection and Thresholding or Suppression Example 1993
Rate-Based Detection with Multiple Filtering Methods Example 1994
Rate-Based Attack Prevention Options and Configuration 1995
Rate-Based Attack Prevention, Detection Filtering, and Thresholding or Suppression 1997
Configuring Rate-Based Attack Prevention 1997

Firepower Management Center Configuration Guide, Version 6.3

lxxi
 Contents

CHAPTER 96 Adaptive Profiles 2001

About Adaptive Profiles 2001
Adaptive Profile Updates 2001
Adaptive Profile Updates and Firepower Recommended Rules 2002
Adaptive Profile Options 2002
Configuring Adaptive Profiles 2003

PART XXIII Discovery and Identity 2005

CHAPTER 97 Introduction to Network Discovery and Identity 2007

About Detection of Host, Application, and User Data 2007
Host, Application, and User Detection 2008
Host and Application Detection Fundamentals 2009
Passive Detection of Operating System and Host Data 2009
Active Detection of Operating System and Host Data 2009
Current Identities for Applications and Operating Systems 2010
Current User Identities 2011
Application and Operating System Identity Conflicts 2011
Netflow Data in the Firepower System 2012
Requirements for Using NetFlow Data 2012
Differences between NetFlow and Managed Device Data 2013
About User Identity 2015
Identity Terminology 2016
About User Identity Sources 2017
Identity Deployments 2018
How to Set Up an Identity Policy 2019
The User Activity Database 2021
The Users Database 2022
Firepower System Host and User Limits 2023
Firepower System Host Limit 2023
Firepower System User Limit 2024

CHAPTER 98 Host Identity Sources 2027

Firepower Management Center Configuration Guide, Version 6.3

lxxii
 Contents

Overview: Host Data Collection 2027

Determining Which Host Operating Systems the System Can Detect 2028
Identifying Host Operating Systems 2028
Custom Fingerprinting 2028
Managing Fingerprints 2029
Activating and Deactivating Fingerprints 2030
Editing an Active Fingerprint 2031
Editing an Inactive Fingerprint 2031
Creating a Custom Fingerprint for Clients 2032
Creating a Custom Fingerprint for Servers 2034
Host Input Data 2037
Requirements for Using Third-Party Data 2037
Third-Party Product Mappings 2038
Mapping Third-Party Products 2038
Mapping Third-Party Product Fixes 2040
Mapping Third-Party Vulnerabilities 2041
Custom Product Mappings 2042
Creating Custom Product Mappings 2042
Editing Custom Product Mapping Lists 2043
Activating and Deactivating Custom Product Mappings 2044
Configuring the Host Input Client 2044
Nmap Scanning 2045
Nmap Remediation Options 2046
Nmap Scanning Guidelines 2052
Example: Using Nmap to Resolve Unknown Operating Systems 2053
Example: Using Nmap to Respond to New Hosts 2055
Managing Nmap Scanning 2056
Adding an Nmap Scan Instance 2056
Editing an Nmap Scan Instance 2058
Adding an Nmap Scan Target 2058
Editing an Nmap Scan Target 2060
Creating an Nmap Remediation 2060
Editing an Nmap Remediation 2062
Running an On-Demand Nmap Scan 2063

Firepower Management Center Configuration Guide, Version 6.3

lxxiii
 Contents

Nmap Scan Results 2064

Viewing Nmap Scan Results 2064
Nmap Scan Results Fields 2065
Importing Nmap Scan Results 2066

CHAPTER 99 Application Detection 2067

Overview: Application Detection 2067
Application Detector Fundamentals 2068
Identification of Application Protocols in the Web Interface 2069
Implied Application Protocol Detection from Client Detection 2070
Host Limits and Discovery Event Logging 2071
Special Considerations for Application Detection 2071
Custom Application Detectors 2072
Custom Application Detector and User-Defined Application Fields 2072
Configuring Custom Application Detectors 2075
Creating a User-Defined Application 2076
Specifying Detection Patterns in Basic Detectors 2077
Specifying Detection Criteria in Advanced Detectors 2078
Testing a Custom Application Protocol Detector 2080
Viewing or Downloading Detector Details 2080
Sorting the Detector List 2081
Filtering the Detector List 2081
Filter Groups for the Detector List 2082
Navigating to Other Detector Pages 2083
Activating and Deactivating Detectors 2083
Editing Custom Application Detectors 2084
Deleting Detectors 2085

CHAPTER 100 Create and Manage Realms 2087

About Realms 2087
Realms and Trusted Domains 2089
Supported Servers for Realms 2089
Supported Server Object Class and Attribute Names 2090
Create a Realm 2092

Firepower Management Center Configuration Guide, Version 6.3

lxxiv
 Contents

Realm Fields 2093

Configure a Realm Directory 2096
Download Users and Groups 2097
Manage a Realm 2098
Compare Realms 2099
Troubleshoot Realms and User Downloads 2100
Detect Realm or User Mismatches 2103

CHAPTER 101 Control Users with ISE/ISE-PIC 2105

The ISE/ISE-PIC Identity Source 2105
ISE/ISE-PIC Guidelines and Limitations 2105
Configure ISE/ISE-PIC for User Control 2107
ISE/ISE-PIC Configuration Fields 2108
Troubleshoot the ISE/ISE-PIC Identity Source 2109
History for ISE/ISE-PIC 2111

CHAPTER 102 Control Users with Captive Portal 2113

The Captive Portal Identity Source 2113
Captive Portal Guidelines and Limitations 2113
How to Configure the Captive Portal for User Control 2115
Configure the Captive Portal Part 1: Create an Identity Policy 2117
Configure the Captive Portal Part 2: Create a TCP Port Access Control Rule 2118
Configure the Captive Portal Part 3: Create a User Access Control Rule 2119
Configure Captive Portal Part 4: Create an SSL Decrypt-Resign Policy 2120
Configure Captive Portal Part 5: Associate Identity and SSL Policies with the Access Control Policy
2121

Captive Portal Fields 2122

Exclude Applications from Captive Portal 2123
Troubleshoot the Captive Portal Identity Source 2124
History for Captive Portal 2125

CHAPTER 103 Control Users with Remote Access VPN 2127

The Remote Access VPN Identity Source 2127
Configure RA VPN for User Control 2128

Firepower Management Center Configuration Guide, Version 6.3

lxxv
 Contents

Troubleshoot the Remote Access VPN Identity Source 2128

History for RA VPN 2129

CHAPTER 104 Control Users with the TS Agent 2131

The Terminal Services (TS) Agent Identity Source 2131
TS Agent Guidelines 2131
Configure the TS Agent for User Control 2132
Troubleshoot the TS Agent Identity Source 2132
History for TS Agent 2133

CHAPTER 105 Control Users with the User Agent 2135

The User Agent Identity Source 2135
User Agent Guidelines 2135
Troubleshoot the User Agent Identity Source 2136
History for the User Agent 2137

CHAPTER 106 Create and Manage Identity Policies 2139

About Identity Policies 2139
Create an Identity Rule 2140
Identity Rule Fields 2141
Create an Identity Policy 2143
Manage an Identity Rule 2144
Manage an Identity Policy 2145

CHAPTER 107 Network Discovery Policies 2147

Overview: Network Discovery Policies 2147
Network Discovery Customization 2148
Configuring the Network Discovery Policy 2148
Network Discovery Rules 2149
Configuring Network Discovery Rules 2150
Actions and Discovered Assets 2150
Monitored Networks 2151
Port Exclusions 2154
Zones in Network Discovery Rules 2156

Firepower Management Center Configuration Guide, Version 6.3

lxxvi
 Contents

The Traffic-Based Detection Identity Source 2156

Configuring Advanced Network Discovery Options 2159
Network Discovery General Settings 2160
Configuring Network Discovery General Settings 2160
Network Discovery Identity Conflict Settings 2161
Configuring Network Discovery Identity Conflict Resolution 2162
Network Discovery Vulnerability Impact Assessment Options 2162
Enabling Network Discovery Vulnerability Impact Assessment 2163
Indications of Compromise 2163
Enabling Indications of Compromise Rules 2164
Adding NetFlow Exporters to a Network Discovery Policy 2165
Network Discovery Data Storage Settings 2165
Configuring Network Discovery Data Storage 2167
Configuring Network Discovery Event Logging 2167
Adding Network Discovery OS and Server Identity Sources 2168
Troubleshooting Your Network Discovery Strategy 2169

PART XXIV Correlation and Compliance 2171

CHAPTER 108 Compliance White Lists 2173

Introduction to Compliance White Lists 2173
Compliance White List Target Networks 2174
Compliance White List Host Profiles 2175
Operating System-Specific Host Profiles 2176
Shared Host Profiles 2176
White List Violation Triggers 2177
Creating a Compliance White List 2178
Setting Target Networks for a Compliance White List 2179
Building White List Host Profiles 2180
White Listing an Application Protocol 2181
White Listing a Client 2182
White Listing a Web Application 2183
White Listing a Protocol 2183
Managing Compliance White Lists 2184

Firepower Management Center Configuration Guide, Version 6.3

lxxvii
 Contents

Editing a Compliance White List 2185

Managing Shared Host Profiles 2186

CHAPTER 109 Correlation Policies 2189

Introduction to Correlation Policies and Rules 2189
Configuring Correlation Policies 2190
Adding Responses to Rules and White Lists 2191
Managing Correlation Policies 2192
Configuring Correlation Rules 2193
Syntax for Intrusion Event Trigger Criteria 2194
Syntax for Malware Event Trigger Criteria 2197
Syntax for Discovery Event Trigger Criteria 2198
Syntax for User Activity Event Trigger Criteria 2201
Syntax for Host Input Event Trigger Criteria 2202
Syntax for Connection Event Trigger Criteria 2203
Syntax for Traffic Profile Changes 2206
Syntax for Correlation Host Profile Qualifications 2208
Syntax for User Qualifications 2211
Connection Trackers 2212
Adding a Connection Tracker 2213
Syntax for Connection Trackers 2213
Syntax for Connection Tracker Events 2216
Sample Configuration for Excessive Connections From External Hosts 2216
Sample Configuration for Excessive BitTorrent Data Transfers 2218
Snooze and Inactive Periods 2220
Correlation Rule Building Mechanics 2220
Adding and Linking Conditions in Correlation Rules 2222
Using Multiple Values in Correlation Rule Conditions 2223
Managing Correlation Rules 2223
Configuring Correlation Response Groups 2224
Managing Correlation Response Groups 2225

CHAPTER 110 Traffic Profiling 2227

Introduction to Traffic Profiles 2227

Firepower Management Center Configuration Guide, Version 6.3

lxxviii
 Contents

Traffic Profile Conditions 2229

Managing Traffic Profiles 2231
Configuring Traffic Profiles 2232
Adding Traffic Profile Conditions 2233
Adding Host Profile Qualifications to a Traffic Profile 2233
Syntax for Traffic Profile Conditions 2234
Syntax for Host Profile Qualifications in a Traffic Profile 2235
Using Multiple Values in a Traffic Profile Condition 2238

CHAPTER 111 Remediations 2239

Introduction to Remediations 2239
Cisco ISE EPS Remediations 2240
Configuring ISE EPS Remediations 2240
Cisco IOS Null Route Remediations 2242
Configuring Remediations for Cisco IOS Routers 2243
Nmap Scan Remediations 2248
Set Attribute Value Remediations 2248
Configuring Set Attribute Remediations 2248
Managing Remediation Modules 2250
Managing Remediation Instances 2251
Managing Instances for a Single Remediation Module 2251

PART XXV Reporting and Alerting 2253

CHAPTER 112 Working with Reports 2255

Introduction to Reports 2255
Risk Reports 2255
Generating, Viewing, and Printing Risk Reports 2255
Standard Reports 2256
About Designing Reports 2257
Report Templates 2257
Report Template Fields 2257
Report Template Creation 2259
Report Template Configuration 2263

Firepower Management Center Configuration Guide, Version 6.3

lxxix
 Contents

Managing Report Templates 2275

About Generating Reports 2277
Generating Reports 2277
Report Generation Options 2279
Distributing Reports by Email at Generation Time 2279
Schedule Future Reports 2280
About Working with Generated Reports 2280
Viewing Reports 2280
Downloading Reports 2281
Storing Reports Remotely 2281
Moving Reports to Remote Storage 2282
Deleting Reports 2283

CHAPTER 113 External Alerting with Alert Responses 2285

Firepower Management Center Alert Responses 2285
Configurations Supporting Alert Responses 2286
Creating an SNMP Alert Response 2286
Creating a Syslog Alert Response 2287
Syslog Alert Facilities 2288
Syslog Severity Levels 2289
Creating an Email Alert Response 2290
Configuring Impact Flag Alerting 2291
Configuring Discovery Event Alerting 2291
Configuring AMP for Networks Alerting 2292

CHAPTER 114 External Alerting for Intrusion Events 2293

About External Alerting for Intrusion Events 2293
Configuring SNMP Alerting for Intrusion Events 2294
Intrusion SNMP Alert Options 2294
Configuring Syslog Alerting for Intrusion Events 2295
Facilities and Severities for Intrusion Syslog Alerts 2296
Configuring Email Alerting for Intrusion Events 2297
Intrusion Email Alert Options 2298

Firepower Management Center Configuration Guide, Version 6.3

lxxx
 Contents

PART XXVI Event and Asset Analysis Tools 2301

CHAPTER 115 Using the Context Explorer 2303

About the Context Explorer 2303
Differences Between the Dashboard and the Context Explorer 2304
The Traffic and Intrusion Event Counts Time Graph 2304
The Indications of Compromise Section 2305
The Hosts by Indication Graph 2305
The Indications by Host Graph 2305
The Network Information Section 2305
The Operating Systems Graph 2305
The Traffic by Source IP Graph 2306
The Traffic by Source User Graph 2306
The Connections by Access Control Action Graph 2306
The Traffic by Destination IP Graph 2307
The Traffic by Ingress/Egress Security Zone Graph 2307
The Application Information Section 2307
Focusing the Application Information Section 2308
The Traffic by Risk/Business Relevance and Application Graph 2308
The Intrusion Events by Risk/Business Relevance and Application Graph 2308
The Hosts by Risk/Business Relevance and Application Graph 2309
The Application Details List 2309
The Security Intelligence Section 2309
The Security Intelligence Traffic by Category Graph 2310
The Security Intelligence Traffic by Source IP Graph 2310
The Security Intelligence Traffic by Destination IP Graph 2310
The Intrusion Information Section 2311
The Intrusion Events by Impact Graph 2311
The Top Attackers Graph 2311
The Top Users Graph 2311
The Intrusion Events by Priority Graph 2311
The Top Targets Graph 2311
The Top Ingress/Egress Security Zones Graph 2312

Firepower Management Center Configuration Guide, Version 6.3

lxxxi
 Contents

The Intrusion Event Details List 2312

The Files Information Section 2312
The Top File Types Graph 2312
The Top File Names Graph 2313
The Files by Disposition Graph 2313
The Top Hosts Sending Files Graph 2313
The Top Hosts Receiving Files Graph 2313
The Top Malware Detections Graph 2314
The Geolocation Information Section 2314
The Connections by Initiator/Responder Country Graph 2314
The Intrusion Events by Source/Destination Country Graph 2314
The File Events by Sending/Receiving Country Graph 2315
The URL Information Section 2315
The Traffic by URL Graph 2315
The Traffic by URL Category Graph 2316
The Traffic by URL Reputation Graph 2316
Refreshing the Context Explorer 2316
Setting the Context Explorer Time Range 2317
Minimizing and Maximizing Context Explorer Sections 2317
Drilling Down on Context Explorer Data 2318
Filters in the Context Explorer 2319
Data Type Field Options 2320
Creating a Filter from the Add Filter Window 2322
Creating a Quick Filter from the Context Menu 2323
Saving Filtered Context Explorer Views 2324
Viewing Filter Data 2324
Deleting a Filter 2324

CHAPTER 116 Using the Network Map 2325

The Network Map 2325
The Hosts Network Map 2326
The Network Devices Network Map 2326
The Mobile Devices Network Map 2327
The Indications of Compromise Network Map 2328

Firepower Management Center Configuration Guide, Version 6.3

lxxxii
 Contents

The Application Protocols Network Map 2328

The Vulnerabilities Network Map 2329
The Host Attributes Network Map 2330
Viewing Network Maps 2330
Custom Network Topologies 2331
Creating Custom Topologies 2331
Importing Networks from the Network Discovery Policy 2332
Manually Adding Networks to Your Custom Topology 2333
Activating and Deactivating Custom Topologies 2333
Editing Custom Topologies 2334

CHAPTER 117 Incidents 2335

About Incident Handling 2335
Definition of an Incident 2335
Common Incident Handling Processes 2336
Incident Types in the Firepower System 2338
Creating Custom Incident Types 2338
Creating an Incident 2339
Editing an Incident 2340
Generating Incident Reports 2340

CHAPTER 118 Using Lookups 2343

Introduction to Lookups 2343
Performing Whois Lookups 2343
Finding URL Category and Reputation 2344
Finding Geolocation Information for an IP Address 2345

CHAPTER 119 Event Analysis Using External Tools 2347

Cisco Firepower App for Splunk 2347
Event Investigation Using Cisco Security Packet Analyzer 2347
Requirements for the Packet Analyzer Deployment 2347
Requirements and Recommendations for the Packet Analyzer Capture Session 2348
Register Packet Analyzer Instances 2349
Query Packet Analyzers 2350

Firepower Management Center Configuration Guide, Version 6.3

lxxxiii
 Contents

View Packet Analyzer Query Status 2351

View Packet Analyzer Query Results 2352
Troubleshoot Packet Analyzer Queries 2353
Event Investigation Using Web-Based Resources 2353
About Managing Contextual Cross-Launch Resources 2354
Requirements for Custom Contextual Cross-Launch Resources 2354
Add Contextual Cross-Launch Resources 2354
Investigate Events Using Contextual Cross-Launch 2356
About Sending Syslog Messages for Connection and Intrusion Events 2356
About Configuring the System to Send Connection and Intrusion Event Data to Syslog 2357
Configuration Locations for Security Event Syslogs 2357
Anatomy of Connection and Intrusion Event Syslog Messages 2360
Facility in Security Event Syslog Messages 2362
Firepower Syslog Message Types 2363
eStreamer Server Streaming 2363
Comparison of Syslog and eStreamer for Security Eventing 2364
Choosing eStreamer Event Types 2365
Configuring eStreamer Client Communications 2365
History for Analyzing Event Data Using External Tools 2366

PART XXVII Workflows 2369

CHAPTER 120 Workflows 2371

Overview: Workflows 2371
Predefined Workflows 2371
Predefined Intrusion Event Workflows 2372
Predefined Malware Workflows 2373
Predefined File Workflows 2374
Predefined Captured File Workflows 2374
Predefined Connection Data Workflows 2374
Predefined Security Intelligence Workflows 2376
Predefined Host Workflows 2376
Predefined Indications of Compromise Workflows 2377
Predefined Applications Workflows 2377

Firepower Management Center Configuration Guide, Version 6.3

lxxxiv
 Contents

Predefined Application Details Workflows 2378

Predefined Servers Workflows 2378
Predefined Host Attributes Workflows 2379
The Predefined Discovery Events Workflow 2379
Predefined User Workflows 2379
Predefined Vulnerabilities Workflows 2380
Predefined Third-Party Vulnerabilities Workflows 2380
Predefined Correlation and White List Workflows 2380
Predefined System Workflows 2381
Custom Table Workflows 2381
Using Workflows 2382
Workflow Access by User Role 2384
Workflow Selection 2384
Workflow Pages 2385
Workflow Page Navigation Tools 2387
Workflow Page Traversal Tools 2387
File Trajectory Icons 2387
Host Profile Icons 2388
Threat Score Icons 2388
User Icons 2388
The Workflow Toolbar 2389
Using Drill-Down Pages 2390
Using Table View Pages 2390
Geolocation 2391
Geolocation Detail Information 2391
Connection Event Graphs 2393
Using Connection Event Graphs 2393
Event Time Constraints 2399
Per-Session Time Window Customization for Events 2400
The Default Time Window for Events 2403
Event View Constraints 2406
Constraining Events 2407
Compound Event View Constraints 2407
Using Compound Event View Constraints 2408

Firepower Management Center Configuration Guide, Version 6.3

lxxxv
 Contents

Inter-Workflow Navigation 2408

Bookmarks 2409
Creating Bookmarks 2410
Viewing Bookmarks 2410

CHAPTER 121 Searching for Events 2413

Event Searches 2413
Search Constraints 2413
General Search Constraints 2414
Wildcards and Symbols in Searches 2414
Objects and Application Filters in Searches 2415
Time Constraints in Searches 2415
IP Addresses in Searches 2416
Managed Devices in Searches 2416
Ports in Searches 2417
Event Fields in Searches 2417
Performing a Search 2418
Saving a Search 2419
Loading a Saved Search 2419
Query Overrides Via the Shell 2420
Shell-Based Query Management Syntax 2420
Stopping Long-Running Queries 2421

CHAPTER 122 Custom Workflows 2423

Introduction to Custom Workflows 2423
Saved Custom Workflows 2423
Custom Workflow Creation 2424
Creating Custom Workflows Based on Non-Connection Data 2426
Creating Custom Connection Data Workflows 2426
Custom Workflow Use and Management 2428
Viewing Custom Workflows Based on Predefined Tables 2428
Viewing Custom Workflows Based on Custom Tables 2428
Editing Custom Workflows 2429

Firepower Management Center Configuration Guide, Version 6.3

lxxxvi
 Contents

CHAPTER 123 Custom Tables 2431

Introduction to Custom Tables 2431
Predefined Custom Tables 2431
Possible Table Combinations 2432
User-Defined Custom Tables 2436
Creating a Custom Table 2436
Modifying a Custom Table 2437
Deleting a Custom Table 2438
Viewing a Workflow Based on a Custom Table 2438
Searching Custom Tables 2439

PART XXVIII Events and Assets 2441

CHAPTER 124 Connection Logging 2443

About Connection Logging 2443
Connections That Are Always Logged 2444
Other Connections You Can Log 2444
How Rules and Policy Actions Affect Logging 2445
Logging for Fastpathed Connections 2446

Logging for Monitored Connections 2446

Logging for Trusted Connections 2446
Logging for Blocked Connections 2447
Logging for Allowed Connections 2448
Beginning vs End-of-Connection Logging 2449
Firepower Management Center vs External Logging 2450
Limitations of Connection Logging 2451
When Events Appear in the Event Viewer 2451
Best Practices for Connection Logging 2451
Configure Connection Logging 2454
Logging Connections with Tunnel and Prefilter Rules 2454
Logging Decryptable Connections with SSL Rules 2455
Logging Connections with Security Intelligence 2455
Logging Connections with Access Control Rules 2456

Firepower Management Center Configuration Guide, Version 6.3

lxxxvii
 Contents

Logging Connections with a Policy Default Action 2457

Limiting Logging of Long URLs 2458

CHAPTER 125 Connection and Security Intelligence Events 2461

About Connection Events 2461
Connection vs. Security Intelligence Events 2461
NetFlow Connections 2462
Connection Summaries (Aggregated Data for Graphs) 2462
Long-Running Connections 2463
Combined Connection Summaries from External Responders 2463
Connection and Security Intelligence Event Fields 2463
About Connection and Security Intelligence Event Fields 2476
Connection Event Reasons 2476
Requirements for Populating Connection Event Fields 2478
Information Available in Connection Event Fields 2479
Using Connection and Security Intelligence Event Tables 2483
Viewing Files and Malware Detected in a Connection 2485
Viewing Intrusion Events Associated with a Connection 2486
Encrypted Connection Certificate Details 2487
Viewing the Connection Summary Page 2487

CHAPTER 126 Working with Intrusion Events 2489

About Intrusion Events 2489
Viewing Intrusion Events 2489
About Intrusion Event Fields 2490
Intrusion Event Fields 2491
Intrusion Event Impact Levels 2500
Viewing Connection Data Associated with Intrusion Events 2502
Marking Intrusion Events Reviewed 2502
Viewing Previously Reviewed Intrusion Events 2503
Marking Reviewed Intrusion Events Unreviewed 2503
Preprocessor Events 2504
Preprocessor Generator IDs 2504
Intrusion Event Workflow Pages 2507

Firepower Management Center Configuration Guide, Version 6.3

lxxxviii
 Contents

Using Intrusion Event Workflows 2508

Intrusion Event Drill-Down Page Constraints 2509
Intrusion Event Table View Constraints 2510
Using the Intrusion Event Packet View 2511
Event Information Fields 2512
Frame Information Fields 2519
Data Link Layer Information Fields 2520
Viewing Network Layer Information 2520
Viewing Transport Layer Information 2523
Viewing Packet Byte Information 2525
The Intrusion Events Clipboard 2526
Generating Clipboard Reports 2526
Deleting Events from the Clipboard 2527
Viewing Intrusion Event Statistics 2527
Host Statistics 2528
Event Overview 2528
Event Statistics 2529
Viewing Intrusion Event Performance Graphs 2529
Intrusion Event Performance Statistics Graph Types 2530
Viewing Intrusion Event Graphs 2534

CHAPTER 127 File/Malware Events and Network File Trajectory 2537

About File/Malware Events and Network File Trajectory 2537
File and Malware Events 2538
File and Malware Event Types 2538
File Events 2538
Malware Events 2538

Retrospective Malware Events 2539

Malware Events Generated by AMP for Endpoints 2539

Using File and Malware Event Workflows 2541
File and Malware Event Fields 2542
Malware Event Sub-Types 2550
Information Available in File and Malware Event Fields 2551
View Details About Analyzed Files 2553

Firepower Management Center Configuration Guide, Version 6.3

lxxxix
 Contents

File Composition Report 2554

View File Details in AMP Private Cloud 2554
Threat Scores and Dynamic Analysis Summary Reports 2554
Viewing Dynamic Analysis Results in the Cisco Threat Grid Public Cloud 2555
Using Captured File Workflows 2556
Captured File Fields 2556
Stored Files Download 2560
Manually Submit Files for Analysis 2561
Network File Trajectory 2562
Recently Detected Malware and Analyzed Trajectories 2562
Network File Trajectory Detailed View 2562
Network File Trajectory Summary Information 2563
Network File Trajectory Map and Related Events List 2564
Using a Network File Trajectory 2565
Work with Event Data in the AMP for Endpoints Console 2567

CHAPTER 128 Using Host Profiles 2569

Host Profiles 2569
Viewing Host Profiles 2571
Basic Host Information in the Host Profile 2571
Operating Systems in the Host Profile 2573
Viewing Operating System Identities 2575
Setting the Current Operating System Identity 2575
Operating System Identity Conflicts 2576
Making a Conflicting Operating System Identity Current 2576
Resolving an Operating System Identity Conflict 2577
Servers in the Host Profile 2578
Server Details in the Host Profile 2579
Viewing Server Details 2580
Editing Server Identities 2581
Resolving Server Identity Conflicts 2582
Web Applications in the Host Profile 2582
Deleting Web Applications from the Host Profile 2583
Host Protocols in the Host Profile 2584

Firepower Management Center Configuration Guide, Version 6.3

xc
 Contents

Deleting a Protocol From the Host Profile 2584

Indications of Compromise in the Host Profile 2585
VLAN Tags in the Host Profile 2585
User History in the Host Profile 2585
Host Attributes in the Host Profile 2586
Predefined Host Attributes 2586
White List Host Attributes 2586
User-Defined Host Attributes 2587
Creating Text- or URL-Based Host Attributes 2588
Creating Integer-Based Host Attributes 2588
Creating List-Based Host Attributes 2589
Setting Host Attribute Values 2589
White List Violations in the Host Profile 2590
Creating Shared White List Host Profiles 2590
Malware Detections in the Host Profile 2591
Vulnerabilities in the Host Profile 2592
Downloading Patches for Vulnerabilities 2593
Deactivating Vulnerabilities for Individual Hosts 2593
Deactivating Individual Vulnerabilities 2594
Scan Results in the Host Profile 2595
Scanning a Host from the Host Profile 2595

CHAPTER 129 Working with Discovery Events 2597

Discovery and Identity Data in Discovery Events 2597
Viewing Discovery Event Statistics 2598
The Statistics Summary Section 2599
The Event Breakdown Section 2600
The Protocol Breakdown Section 2600
The Application Protocol Breakdown Section 2600
The OS Breakdown Section 2600
Viewing Discovery Performance Graphs 2601
Discovery Performance Graph Types 2601
Using Discovery and Identity Workflows 2602
Discovery and Host Input Events 2604

Firepower Management Center Configuration Guide, Version 6.3

xci
Contents

Discovery Event Types 2604

Host Input Event Types 2608
Viewing Discovery and Host Input Events 2610
Discovery Event Fields 2610
Host Data 2612
Viewing Host Data 2612
Host Data Fields 2613
Creating a Traffic Profile for Selected Hosts 2616
Creating a Compliance White List Based on Selected Hosts 2617
Host Attribute Data 2617
Viewing Host Attributes 2618
Host Attribute Data Fields 2618
Setting Host Attributes for Selected Hosts 2619
Indications of Compromise Data 2620
View and Work with Indications of Compromise Data 2620
Indications of Compromise Data Fields 2622
Editing Indication of Compromise Rule States for a Single Host or User 2623
Viewing Source Events for Indication of Compromise Tags 2623
Resolving Indication of Compromise Tags 2624
Server Data 2624
Viewing Server Data 2625
Server Data Fields 2625
Application and Application Details Data 2628
Viewing Application Data 2628
Application Data Fields 2629
Viewing Application Detail Data 2630
Application Detail Data Fields 2631
Vulnerability Data 2633
Vulnerability Data Fields 2633
Vulnerability Deactivation 2635
Viewing Vulnerability Data 2636
Viewing Vulnerability Details 2637
Deactivating Multiple Vulnerabilities 2637
Third-Party Vulnerability Data 2638

Firepower Management Center Configuration Guide, Version 6.3

xcii
 Contents

Viewing Third-Party Vulnerability Data 2638

Third-Party Vulnerability Data Fields 2639
Active Sessions, Users, and User Activity Data 2640
User-Related Fields 2640
Active Sessions Data 2646
User Data 2647
User Activity Data 2650
User Profile and Host History 2652

CHAPTER 130 Correlation and Compliance Events 2655

Viewing Correlation Events 2655
Correlation Event Fields 2656
Using Compliance White List Workflows 2659
Viewing White List Events 2660
White List Event Fields 2661
Viewing White List Violations 2662
White List Violation Fields 2663
Remediation Status Events 2664
Viewing Remediation Status Events 2664
Remediation Status Table Fields 2665
Using the Remediation Status Events Table 2666

CHAPTER 131 Auditing the System 2669

About System Auditing 2669
About Sending Audit Logs to an External Location 2669
Audit Records 2670
Viewing Audit Records 2670
Audit Log Workflow Fields 2671
The Audit Events Table View 2672
Using the Audit Log to Examine Changes 2672
Suppressing Audit Records 2673
Audit Block Types 2674
Audited Subsystems 2675
The System Log 2677

Firepower Management Center Configuration Guide, Version 6.3

xciii
 Contents

Viewing the System Log 2677

Syntax for System Log Filters 2678

APPENDIX A Security, Internet Access, and Communication Ports 2679

Security Requirements 2679
Internet Access Requirements 2679
Communication Port Requirements 2681

APPENDIX B Classic Device Command Line Reference 2685

About the Classic Device CLI 2685
Classic Device CLI Modes 2686
Classic Device CLI Access Levels 2686
Classic Device CLI Management Commands 2686
configure password 2686
exit 2687
expert 2687
history 2688
logout 2688
? (question mark) 2688
Classic Device CLI Show Commands 2689
access-control-config 2689
alarms 2690
arp-tables 2690
audit-log 2690
audit_cert 2691
bypass 2691
high-availability Commands 2692
config 2692
high-availability ha-statistics 2692
cpu 2692
database Commands 2693
processes 2693
slow-query-log 2694
device-settings 2694

Firepower Management Center Configuration Guide, Version 6.3

xciv
 Contents

disk 2694
disk-manager 2695
dns 2695
fan-status 2696
fastpath-rules 2696
gui 2696
hostname 2697
hosts 2697
http-cert-expire-date 2697
hyperthreading 2698
inline-sets 2698
interfaces 2699
ifconfig 2699
lcd 2699
link-aggregation Commands 2700
configuration 2700
statistics 2700
link-state 2701
log-ips-connection 2701
managers 2701
memory 2702
model 2702
mpls-depth 2702
NAT Commands 2703
active-dynamic 2703
active-static 2703
allocators 2704
config 2704
dynamic-rules 2704
flows 2704
static-rules 2705
netstat 2705
network 2705
network-modules 2706

Firepower Management Center Configuration Guide, Version 6.3

xcv
Contents

network-static-routes 2706
ntp 2706
perfstats 2707
portstats 2707
power-supply-status 2708
process-tree 2708
processes 2709
route 2709
routing-table 2709
serial-number 2710
ssl-policy-config 2710
stacking 2711
summary 2711
syslog 2711
time 2712
traffic-statistics 2712
user 2713
users 2714
version 2714
virtual-routers 2715
virtual-switches 2715
vmware-tools 2716
VPN Commands 2716
config 2717
config by virtual router 2717
status 2717
status by virtual router 2717
counters 2718
counters by virtual router 2718
Classic Device CLI Configuration Commands 2718
audit_cert Commands 2718
delete 2719
import 2719
bypass 2720

Firepower Management Center Configuration Guide, Version 6.3

xcvi
 Contents

high-availability 2720
gui 2720
lcd 2721
log-ips-connections 2721
manager Commands 2721
add 2722
delete 2722
mpls-depth 2722
network Commands 2723
dns searchdomains 2723
dns servers 2723
hostname 2724
http-proxy 2724
http-proxy-disable 2725
ipv4 delete 2725
ipv4 dhcp 2725
ipv4 manual 2726
ipv6 delete 2726
ipv6 dhcp 2726
ipv6 manual 2727
ipv6 router 2727
management-interface disable 2728
management-interface disable-event-channel 2728
management-interface disable-management-channel 2728
management-interface enable 2729
management-interface enable-event-channel 2730
management-interface enable-management-channel 2730
management-interface tcpport 2730
management-port 2731
static-routes ipv4 add 2731
static-routes ipv4 delete 2731
static-routes ipv6 add 2732
static-routes ipv6 delete 2732
password 2732

Firepower Management Center Configuration Guide, Version 6.3

xcvii
Contents

stacking disable 2733

user Commands 2733
access 2734
add 2734
aging 2734
delete 2735
disable 2735
enable 2735
forcereset 2735
maxfailedlogins 2736
minpasswdlen 2736
password 2736
strengthcheck 2737
unlock 2737
vmware-tools 2737
Classic Device CLI System Commands 2738
access-control Commands 2738
archive 2738
clear-rule-counts 2739
rollback 2739
compliance Commands 2739
enable cc 2739
enable ucapl 2740
show 2740
disable-http-user-cert 2740
file Commands 2741
copy 2741
delete 2741
list 2742
secure-copy 2742
generate-troubleshoot 2742
ldapsearch 2743
lockdown 2744
nat rollback 2744

Firepower Management Center Configuration Guide, Version 6.3

xcviii
 Contents

renew-http-cert 2745
reboot 2745
restart 2745
support Commands 2746
ssl-client-hello-display 2746
ssl-client-hello-enabled 2746
ssl-client-hello-force-reset 2748
ssl-client-hello-reset 2748
ssl-client-hello-tuning 2749
shutdown 2750
History for Classic Device CLI 2751

APPENDIX C Firepower Management Center Command Line Reference 2753

About the Firepower Management Center CLI 2753
Firepower Management Center CLI Modes 2754
Enabling the Firepower Management Center CLI 2754
Firepower Management Center CLI Management Commands 2755
exit 2755
expert 2755
? (question mark) 2755
Firepower Management Center CLI Show Commands 2756
version 2756
Firepower Management Center CLI Configuration Commands 2756
password 2756
Firepower Management Center CLI System Commands 2757
generate-troubleshoot 2757
lockdown 2758
reboot 2758
restart 2758
shutdown 2759
History for the Firepower Management Center CLI 2759

Firepower Management Center Configuration Guide, Version 6.3

xcix
Contents

Firepower Management Center Configuration Guide, Version 6.3

c
 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 1

• Firepower Devices, on page 6
• Firepower Features, on page 7
• Firepower Online Help, How To, and Documentation, on page 11
• Firepower System IP Address Conventions, on page 15
• Additional Resources, on page 15

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.

Firepower Management Center Configuration Guide, Version 6.3

1
 Getting Started With Firepower
Installing and Performing Initial Setup on Physical Appliances

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.

• Firepower Threat Defense for the 2100: Cisco Firepower Threat Defense for the Firepower 2100
Series Using Firepower Management Center Quick Start Guide
http://www.cisco.com/go/ftd-quick
• Firepower Threat Defense for the 4100: Cisco Firepower Threat Defense for Firepower 4100 Quick
Start Guide
http://www.cisco.com/go/ftd-quick
• Firepower Threat Defense for the 9300: Cisco Firepower Threat Defense for Firepower 9300 Quick
Start Guide
http://www.cisco.com/go/ftd-quick
• Firepower Threat Defense for the ASA 5508-X/5516-X: Cisco Firepower Threat Defense for the
ASA 5508-X and ASA 5516-X Using Firepower Management Center Quick Start Guide
http://www.cisco.com/go/ftd-quick
• Firepower Threat Defense for the ASA 5500-X: Cisco Firepower Threat Defense for the ASA
5512-X, ASA 5515-X, ASA 5525-X, ASA 5545-X, and ASA 5555-X Using Firepower Management
Center Quick Start Guide
http://www.cisco.com/go/ftd-quick
• Firepower Threat Defense for the ISA 3000: Cisco Firepower Threat Defense for the ISA 3000
Using Firepower Management Center Quick Start Guide
http://www.cisco.com/go/ftd-quick

• Classic managed devices

• ASA FirePOWER Services managed device: Cisco ASA FirePOWER Module Quick Start Guide
http://www.cisco.com/go/asafp-quick
• 8000 Series managed device: Cisco Firepower 8000 Series Getting Started Guide
http://www.cisco.com/go/8000series-install

Firepower Management Center Configuration Guide, Version 6.3

2
 Getting Started With Firepower
Deploying Virtual Appliances

• 7000 Series managed device: Cisco Firepower 7000 Series Getting Started Guide
http://www.cisco.com/go/7000series-install

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.

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
Deployment Quick Start Guide
• Firepower Threat Defense Virtual running on Azure: Cisco Firepower Threat Defense Virtual for Azure
Deployment Quick Start Guide

Firepower Management Center Configuration Guide, Version 6.3

3
 Getting Started With Firepower
Logging In for the First Time

Logging In for the First Time

Before you begin
• Prepare your appliances as described in Installing and Performing Initial Setup on Physical Appliances,
on page 2 or Deploying Virtual Appliances, on page 3.

Procedure

Step 1 Log in to the Firepower Management Center web interface with admin as the username and Admin123 as
the password. Change the password for this account as described in the Quick Start Guide for your appliance.
Step 2 Set a time zone for this account as described in Setting Your Default Time Zone, on page 41.
Step 3 Add licenses as described in Licensing the Firepower System, on page 79.
Step 4 Register managed devices as described in Add Devices to the Firepower Management Center, on page 499.
Step 5 Configure your managed devices as described in:
• Introduction to IPS Device Deployment and Configuration, on page 535, to configure passive or inline
interfaces on 7000 Series or 8000 Series devices
• Interface Overview for Firepower Threat Defense, on page 631, to configure transparent or routed mode
on Firepower Threat Defense devices
• Interface Overview for Firepower Threat Defense, on page 631, to configure interfaces on Firepower
Threat Defense devices

What to do next
• Begin controlling and analyzing traffic by configuring basic policies as described in Setting Up Basic
Policies and Configurations, on page 4.

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, set your time zone, add licenses, register devices, and configure devices as
described in Logging In for the First Time, on page 4.

Firepower Management Center Configuration Guide, Version 6.3

4
Getting Started With Firepower
Setting Up Basic Policies and Configurations

Procedure

Step 1 Configure an access control policy as described in Creating a Basic Access Control Policy, on page 1355.
• 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 1351 and
System-Provided Network Analysis and Intrusion Policies, on page 1641.
• 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 2443.

Step 2 Apply the system-provided default health policy as described in Applying Health Policies, on page 249.
Step 3 Customize a few of your system configuration settings:
• If you want to allow inbound connections for a service (for example, SNMP or the syslog), modify the
ports in the access list as described in Configuring the Access List for Your System, on page 1030.
• Understand and consider editing your database event limits as described in Configuring Database Event
Limits, on page 1004.
• If you want to change the display language, edit the language setting as described in Specifying a Different
Language, on page 1042.
• If your organization restricts network access using a proxy server and you did not configure proxy settings
during initial configuration, edit your proxy settings as described in Configure Firepower Management
Center Management Interfaces, on page 1012.

Step 4 Customize your network discovery policy as described in Configuring the Network Discovery Policy, on page
2148. 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 5 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 286.
• If you want to customize the default values for system variables, understand their use as described in
Variable Sets, on page 382.
• If you want to update the Geolocation Database, update manually or on a scheduled basis as described
in Update the Geolocation Database (GeoDB), on page 148.
• If you want to create additional locally authenticated user accounts to access the appliance, see Add an
Internal User Account, on page 47.
• If you want to use LDAP or RADIUS external authentication to allow access to the appliance, see
Configure External Authentication, on page 51.

Step 6 Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

5
 Getting Started With Firepower
Firepower Devices

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 installed on network segments monitor traffic for
analysis and report to either a physical or virtual Firepower Management Center. The Firepower Management
Center provides a centralized management console with graphical user interface that you can use to perform
administrative, management, analysis, and reporting tasks.
This section describes the Firepower implementations you can install on traffic-handling devices and manage
with the Firepower Management Center.
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 Compatibility Guide,
available on the documentation roadmap: http://www.cisco.com/c/en/us/td/docs/security/firepower/roadmap/
firepower-roadmap.html.

Firepower Threat Defense (NGFW)

Lightweight software that provides a unified next-generation firewall (NGFW) and next-generation IPS
(NGIPS) device, on either a physical or virtual platform. In addition to the NGIPS features available on
Firepower software models, 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.

Firepower Software (NGIPS)

NGIPS software running on 7000 and 8000 Series Firepower devices, or hosted on VMware.

ASA with FirePOWER Services (NGIPS)

NGIPS software running on an ASA device. The ASA device provides the first-line system policy, then passes
traffic to an ASA FirePOWER module for discovery and access control.
ASA FirePOWER has a software and a command line interface (CLI) unique to the ASA platform. You use
these ASA-specific tools to install the system and to perform other platform-specific administrative tasks.
ASA FirePOWER does not support the following Firepower features:
• Features for Firepower hardware—Use the ASA CLI and ASDM to configure device high availability,
stacking, switching, routing, VPN, NAT, and so on. See the ASA documentation for more information.
• Interface configuration—You cannot use the Firepower Management Center web interface to configure
ASA FirePOWER interfaces. The Firepower Management Center does not display ASA interfaces when
the ASA FirePOWER is deployed in SPAN port mode.
• Process management—You cannot use the Firepower Management Center to shut down, restart, or
otherwise manage ASA FirePOWER processes.

Firepower Management Center Configuration Guide, Version 6.3

6
 Getting Started With Firepower
Firepower Features

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/
firepower-roadmap.html.

If you want to... Configure... As described in...

Manage user accounts for logging in to Firepower authentication About User Accounts, on page
your Firepower appliances 43

Monitor the health of system hardware Health monitoring policy About Health Monitoring, on
and software page 239

Back up data on your appliance Backup and restore Backup and Restore Support, on
page 161

Upgrade to a new Firepower version System updates Firepower Management Center

Upgrade Guide
Firepower Release Notes

Baseline your physical appliance Restore to factory defaults The Firepower Management
(reimage) Center Upgrade Guide, for a list
of links to instructions on
performing fresh installations.
Update the VDB, intrusion rule updates, Vulnerability Database (VDB) System Software Updates, on
or GeoDB on your appliance updates, intrusion rule updates, page 145
or Geolocation Database
(GeoDB) updates

Apply licenses in order to take advantage Classic licensing or Smart About Firepower Licenses, on
of license-controlled functionality licensing page 79

Ensure continuity of appliance operations Managed device high About 7000 and 8000 Series
availability and/or Firepower Device High Availability, on
Management Center high page 549
availability
About Firepower Threat Defense
High Availability, on page 703
About Firepower Management
Center High Availability, on
page 477

Combine processing resources of Device stacking About Device Stacks, on page

multiple 8000 Series devices 565

Firepower Management Center Configuration Guide, Version 6.3

7
 Getting Started With Firepower
High Availability, Clustering, and Stacking Features by Appliance

If you want to... Configure... As described in...

Configure a device to route traffic Routing Virtual Routers, on page 1279
between two or more interfaces
Routing Overview for Firepower
Threat Defense, on page 763

Configure packet switching between two Device switching Virtual Switches, on page 1269
or more networks
Configure Bridge Group
Interfaces, on page 653

Translate private addresses into public Network Address Translation NAT Policy Configuration, on
addresses for internet connections (NAT) page 1151
Network Address Translation
(NAT) for Firepower Threat
Defense, on page 1169

Establish a secure tunnel between Site-to-Site virtual private VPN Overview for Firepower
managed Firepower Threat Defense or network (VPN) Threat Defense, on page 845
7000/8000 Series devices

Establish secure tunnels between remote Remote Access VPN VPN Overview for Firepower
users and managed Firepower Threat Threat Defense, on page 845
Defense devices

Segment user access to managed devices, Multitenancy using domains Introduction to Multitenancy
configurations, and events Using Domains, on page 297

View and manage appliance REST API and REST API REST API Preferences, on page
configuration using a REST API client Explorer 1061
Firepower REST API Quick
Start Guide

Troubleshoot issues N/A Troubleshooting the System, on

page 279

High Availability, Clustering, and Stacking Features by Appliance

You can deploy Firepower appliances in high availability, clustered, and stacked configurations, as described
below.
High availability configurations (sometimes called failover) ensure continuity of operations. Clustered and
stacked configurations group multiple devices together as a single logical device, achieving increased throughput
and redundancy.

Appliance High Availability Clustering Stacking

Firepower Management Center yes no no

Firepower Management Center Virtual no no no

Firepower Management Center Configuration Guide, Version 6.3

8
 Getting Started With Firepower
Features for Detecting, Preventing, and Processing Potential Threats

Appliance High Availability Clustering Stacking

Firepower NGIPS running on: yes no no

Firepower 7010, 7020, 7030, 7050
Firepower 7110, 7115, 7120, 7125, AMP7150
Firepower 8120, 8130, AMP8050, AMP8150

Firepower NGIPS running on: yes no yes

Firepower 8140
Firepower 8250, 8260, 8270, 8290
Firepower 8350, 8360, 8370, 8390, AMP8350

Firepower Threat Defense running on: yes no no

Virtual: VMware
Virtual: KVM

Firepower Threat Defense running on: no no no

Public Cloud: AWS
Public Cloud: Azure

Firepower Threat Defense running on: yes no no

ASA 5500-X series

Firepower Threat Defense running on: yes yes no

Firepower 9300

Firepower Threat Defense running on: yes yes no

Firepower 4100 series

Firepower Threat Defense running on: yes no no

Firepower 2100 series

Firepower Threat Defense running on: yes no no

ISA 3000

Related Topics
About 7000 and 8000 Series Device High Availability, on page 549
About Firepower Threat Defense High Availability, on page 703
About Firepower Management Center High Availability, on page 477

Features for Detecting, Preventing, and Processing Potential Threats

To locate unfamiliar documents, see: http://www.cisco.com/c/en/us/td/docs/security/firepower/roadmap/
firepower-roadmap.html.

Firepower Management Center Configuration Guide, Version 6.3

9
 Getting Started With Firepower
Features for Detecting, Preventing, and Processing Potential Threats

If you want to... Configure... As described in...

Inspect, log, and take action on network Access control policy, the parent Introduction to Access Control,
traffic of several other policies on page 1349

Blacklist connections to or from IP Security Intelligence within your About Security Intelligence, on
addresses, URLs, and/or domain names access control policy page 1405

Control the websites that users on your URL filtering within your policy URL Filtering, on page 1389
network can access rules

Monitor malicious traffic and intrusions Intrusion policy Intrusion Policy Basics, on page
on your network 1667

Block encrypted traffic without SSL policy SSL Policies Overview, on page
inspection 1475
Inspect encrypted or decrypted traffic

Tailor deep inspection to encapsulated Prefilter policy About Prefiltering, on page 1423
traffic and improve performance with
fastpathing

Rate limit network traffic that is allowed Quality of Service (QoS) policy About QoS Policies, on page 693
or trusted by access control

Allow or block files (including malware) File/malware policy File Policies and Advanced
on your network Malware Protection, on page 1547

Operationalize data from threat Cisco Threat Intelligence Cisco Threat Intelligence
intelligence sources Director (TID) Director (TID) Overview, on
page 1589

Configure passive or active user User awareness, user identity, About User Identity Sources, on
authentication to perform user awareness identity policies page 2017
and user control
About Identity Policies, on page
2139

Collect host, application, and user data Network Discovery policies Overview: Network Discovery
from traffic on your network to perform Policies, on page 2147
user awareness

Use external tools to collect and analyze Integration with external tools Event Analysis Using External
data about network traffic and potential Tools, on page 2347
threats

Perform application detection and control Application detectors Overview: Application

Detection, on page 2067

Troubleshoot issues N/A Troubleshooting the System, on

page 279

Firepower Management Center Configuration Guide, Version 6.3

10
 Getting Started With Firepower
Integration with External Tools

Integration with External Tools

To locate unfamiliar documents, see: http://www.cisco.com/c/en/us/td/docs/security/firepower/roadmap/
firepower-roadmap.html.

If you want to... Configure... As described in...

Automatically launch remediations when Remediations Introduction to Remediations,
conditions on your network violate an on page 2239
associated policy
Firepower System Remediation
API Guide

Stream event data from a Firepower eStreamer integration eStreamer Server Streaming, on
Management Center to a page 2363
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 1002
client
Firepower System Database
Access Guide

Augment discovery data by importing Host input Host Input Data, on page 2037
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 2347
resources

Troubleshoot issues N/A Troubleshooting the System, on

page 279

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 deselect the Enable How-Tos checkbox in the How-To Settings tab.

Firepower Management Center Configuration Guide, Version 6.3

11
 Getting Started With Firepower
Top-Level Documentation Listing Pages for Firepower Management Center Deployments

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:

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

Top-Level Documentation Listing Pages for Firepower Management Center

Deployments
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:

Firepower Management Center Configuration Guide, Version 6.3

12
Getting Started With Firepower
Top-Level Documentation Listing Pages for Firepower Management Center Deployments

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

Firepower Threat Defense, also called NGFW (Next Generation Firewall) devices
• Firepower Threat Defense software:
http://www.cisco.com/c/en/us/support/security/firepower-ngfw/tsd-products-support-series-home.html
• Firepower Threat Defense Virtual:
http://www.cisco.com/c/en/us/support/security/firepower-ngfw-virtual/
tsd-products-support-series-home.html
• Firepower 2100 series:
https://www.cisco.com/c/en/us/support/security/firepower-2100-series/
tsd-products-support-series-home.html
• Firepower 4100 series:
https://www.cisco.com/c/en/us/support/security/firepower-4100-series/
tsd-products-support-series-home.html
• Firepower 9300:
https://www.cisco.com/c/en/us/support/security/firepower-9000-series/
tsd-products-support-series-home.html
• ASA 5500-X series:
• https://www.cisco.com/c/en/us/support/security/asa-firepower-services/
tsd-products-support-series-home.html
• https://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/
tsd-products-support-series-home.html

• ISA 3000:
https://www.cisco.com/c/en/us/support/security/industrial-security-appliance-isa/
tsd-products-support-series-home.html

Classic devices, also called NGIPS (Next Generation Intrusion Prevention System) devices
• ASA with FirePOWER Services:
• ASA 5500-X with FirePOWER Services:
• https://www.cisco.com/c/en/us/support/security/asa-firepower-services/
tsd-products-support-series-home.html
• https://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/
tsd-products-support-series-home.html

Firepower Management Center Configuration Guide, Version 6.3

13
 Getting Started With Firepower
License Statements in the Documentation

• Firepower 8000 series:

https://www.cisco.com/c/en/us/support/security/firepower-8000-series-appliances/
tsd-products-support-series-home.html
• Firepower 7000 series:
https://www.cisco.com/c/en/us/support/security/firepower-7000-series-appliances/
tsd-products-support-series-home.html
• AMP for Networks:
https://www.cisco.com/c/en/us/support/security/amp-appliances/tsd-products-support-series-home.html
• NGIPSv (virtual device):
https://www.cisco.com/c/en/us/support/security/ngips-virtual-appliance/
tsd-products-support-series-home.html

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 79.
Related Topics
About Firepower Licenses, on page 79

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, stacking is supported only on 8000 Series
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.

Firepower Management Center Configuration Guide, Version 6.3

14
 Getting Started With Firepower
Firepower System IP Address Conventions

For more information about user roles, see User Roles, on page 45 and Customize User Roles for the Web
Interface, on page 68.

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.
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.

Firepower Management Center Configuration Guide, Version 6.3

15
 Getting Started With Firepower
Additional Resources

Firepower Management Center Configuration Guide, Version 6.3

16
PA R T I
Your User Account
• Logging into the Firepower System, on page 19
• Specifying User Preferences, on page 35
• User Accounts for Management Access, on page 43
 CHAPTER 2
Logging into the Firepower System
The following topics describe how to log into the Firepower System:
• Firepower System User Accounts, on page 19
• User Interfaces in Firepower Management Center Deployments, on page 21
• Logging Into the Firepower Management Center Web Interface, on page 24
• Logging Into the Web Interface of a 7000 or 8000 Series Device, on page 25
• Logging Into the Firepower Management Center with CAC Credentials, on page 26
• Logging Into a 7000 or 8000 Series Device with CAC Credentials, on page 27
• Logging Into the Command Line Interface on Classic Devices, on page 27
• Logging Into the Command Line Interface on FTD Devices, on page 28
• Viewing Basic System Information in the Web Interface, on page 30
• Switching Domains on the Firepower Management Center, on page 30
• Logging Out of a Firepower System Web Interface, on page 31
• The Context Menu, on page 31
• History for Logging into the Firepower System, on page 33

Firepower System User Accounts

You must provide a username and password to obtain local access to the web interface, shell, or CLI on an
appliance. The features you can access on login are controlled by the privileges granted to your user account.
Some appliances can be configured to use external authorization, storing user credentials on an external LDAP
or RADIUS server.

Note Because the system audits user activity based on user accounts, make sure that users log into the system with
the correct account.

Firepower Management Center Configuration Guide, Version 6.3

19
 Your User Account
Firepower System User Accounts

Caution On all devices, users with CLI or shell access can obtain root privileges in the 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 shell access
appropriately.
• When granting CLI access privileges, restrict the list of users with Config level access.
• Do not establish shell users in addition to the pre-defined admin on any Firepower device.

Caution We strongly recommend that you do not access Firepower devices using the shell or CLI expert mode, unless
directed by Cisco TAC.

Different devices 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.
• A pre-defined admin account for CLI or shell access, which can obtain root privileges. By default, when
this admin account logs into the device, it has direct access to the shell. But when the Firepower
Management Center CLI is enabled, users logging in with this account must use the expert command
to gain access to the shell.
• Custom user accounts, which admin users and users with the administrator role can create and manage.

Caution For system security reasons, Cisco strongly recommends that you not establish additional CLI or shell users
on the Firepower Management Center. If you accept that risk, you can use external authentication to grant
any user CLI or shell access to the Firepower Management Center. You cannot enable CLI or shell access for
internal web interface users.

7000 & 8000 Series Devices

7000 & 8000 Series 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 the administrator role can create and manage.

The 7000 & 8000 Series supports external authentication for users.

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.

Firepower Management Center Configuration Guide, Version 6.3

20
 Your User Account
User Interfaces in Firepower Management Center Deployments

• Custom user accounts, which admin users and users with Config access can create and manage.

The NGIPSv does not support external authentication for users.

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.
• Custom user accounts, which admin users and users with Config access can create and manage.

The Firepower Threat Defense supports external authentication for SSH users.

ASA FirePOWER Devices

The ASA FirePOWER module supports the following user account types:
• A pre-defined admin account.
• Custom user accounts, which admin users and users with Configu access can create and manage.

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.

User Interfaces in Firepower Management Center Deployments

Depending on device type, you can access 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 Firepower Management Center's GUI. Only a few tasks require that you access the device directly.
For information on browser requirements, see the Firepower Release Notes.

Note On all devices, after a user makes three consecutive failed attempts to log into the CLI or shell via SSH, the
system terminates the SSH connection.

Firepower Management Center Configuration Guide, Version 6.3

21
 Your User Account
User Interfaces in Firepower Management Center Deployments

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 and custom
user accounts external user accounts external user accounts
• Can be used for • Accessible only when • Default form of access for
administrative, enabled; see Enabling the supported users, but must
management, and analysis Firepower Management be accessed via expert
tasks Center CLI, on page 2754. command when the
Firepower Management
• Accessible using an SSH, Center CLI is enabled. ;
serial, or keyboard and see Enabling the Firepower
monitor connection Management Center CLI,
• Should be used only for on page 2754
administration and • Accessible using an SSH,
troubleshooting directed by serial, or keyboard and
Cisco TAC monitor connection
• Should be used only for
administration and
troubleshooting directed by
Cisco TAC

7000 & 8000 Series devices • Supported for predefined • Supported for predefined • Supported for predefined
admin user and custom admin user and custom admin user and custom
user accounts user accounts user accounts
• Can be used for initial • Accessible using an SSH, • Accessible by CLI users
setup, basic analysis, and serial, or keyboard and with Config access using
configuration tasks only monitor connection the expert command
• Can be used for setup and • Should be used only for
troubleshooting directed by administration and
Cisco TAC troubleshooting directed by
Cisco TAC

Firepower Threat Defense None • 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.
Accesible in virtual • Should be used only for
devices via SSH or VM administration and
console. troubleshooting directed by
Cisco TAC
• Can be used for setup and
troubleshooting directed by
Cisco TAC

Firepower Management Center Configuration Guide, Version 6.3

22
 Your User Account
Web Interface Considerations

Appliance Web-Based GUI Auxiliary CLI Linux Shell

NGIPSv None • Supported for predefined • Supported for predefined

admin user and custom admin user and custom
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

ASA FirePOWER module None • Supported for predefined None

admin user and custom
user accounts
• Accessible using an SSH
connection. Also
accessible using keyboard
and monitor connection for
ASA-5585-X (hardware
module), or console port
for ASA 5512-X through
ASA 5555-X and ASA
5506-X through 5516-X
(software modules)
• Can be used for
configuration and
management tasks

Related Topics
Add an Internal User Account, on page 47

Web Interface Considerations

• If your organization uses Common Access Cards (CACs) for authentication, you can use your CAC
credentials to obtain access to the web interface of an appliance.
• The first time you visit the appliance home page during a web session, you can view information about
your last login session for that appliance. You can see the following information about your last login:
• the day of the week, month, date, and year of the login
• the appliance-local time of the login in 24-hour notation
• the host and domain name last used to access the 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

Firepower Management Center Configuration Guide, Version 6.3

23
 Your User Account
Session Timeout

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 36

Session Timeout
By default, the Firepower System automatically logs you out of a session after 1 hour of inactivity, unless
you are otherwise configured to be exempt from session timeout.
Users with the Administrator role can change the session timeout interval for an appliance via the following
settings:

Appliance Setting

Firepower Management Center System > Configuration > Shell Timeout

7000 & 8000 Series devices Devices > Platform Settings > Shell Timeout

Related Topics
Configuring Session Timeouts, on page 1052

Logging Into the Firepower Management Center Web Interface

Smart License Classic License Supported Devices Supported Domains Access

N/A Any FMC Any Any

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.

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, on page 47.

Procedure

Step 1 Direct your browser to https://hostname/, where hostname corresponds to the host name of the Firepower
Management Center.
Step 2 In the Username and Password fields, enter your user name and password. Pay attention to the following
guidelines:

Firepower Management Center Configuration Guide, Version 6.3

24
 Your User Account
Logging Into the Web Interface of a 7000 or 8000 Series Device

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

Step 3 Click Login.

Related Topics
Session Timeout, on page 24

Logging Into the Web Interface of a 7000 or 8000 Series Device

Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 & 8000 Series N/A Any

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.

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.
• Complete the initial setup process and create user accounts as described in the Firepower getting started
guide appropriate to the device, and Add an Internal User at the Web Interface, on page 47.

Procedure

Step 1 Direct your browser to https://hostname/, where hostname corresponds to the host name of the managed
device you want to access.
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.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

25
 Your User Account
Logging Into the Firepower Management Center with CAC Credentials

Step 3 Click Login.

Related Topics
Session Timeout, on page 24

Logging Into the Firepower Management Center with CAC

Credentials
Smart License Classic License Supported Devices Supported Domains Access

N/A Any FMC Any Any

Users are restricted to a single active session.

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, on page 47.
• Configure CAC authentication and authorization as described in Configure Common Access Card
Authentication with LDAP, on page 66.

Procedure

Step 1 Insert a CAC as instructed by your organization.

Step 2 Direct your browser to https://hostname/, where hostname corresponds to the host name of the Firepower
Management Center.
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.

Related Topics
Configure Common Access Card Authentication with LDAP, on page 66
Session Timeout, on page 24

Firepower Management Center Configuration Guide, Version 6.3

26
 Your User Account
Logging Into a 7000 or 8000 Series Device with CAC Credentials

Logging Into a 7000 or 8000 Series Device with CAC Credentials

Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 & 8000 Series N/A Any

Users are restricted to a single active session.

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 Add an Internal User at the Web Interface, on page 47.
• Configure CAC authentication and authorization as described in Configure Common Access Card
Authentication with LDAP, on page 66.

Procedure

Step 1 Insert a CAC as instructed by your organization.

Step 2 Direct your browser to https://hostname/, where hostname corresponds to the host name of the appliance
you want to access.
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.

Related Topics
Configure Common Access Card Authentication with LDAP, on page 66
Session Timeout, on page 24

Logging Into the Command Line Interface on Classic Devices

Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 & 8000 Series N/A CLI Basic

Configuration
ASA FirePOWER
NGIPSv

Firepower Management Center Configuration Guide, Version 6.3

27
 Your User Account
Logging Into the Command Line Interface on FTD Devices

You can log directly into the command line interface on Classic managed devices (7000 & 8000 Series,
NGIPSv, and ASA FirePOWER).

Note On all devices, after a user makes three consecutive failed attempts to log into the CLI or shell via SSH, the
system terminates the SSH connection.

Before you begin

Complete the initial setup process using the default admin user for the initial login.
• For the 7000 & 8000 Series devices, create user accounts at the web interface as described in Add an
Internal User at the Web Interface, on page 47.
• For all devices, create additional user accounts that can log into the CLI using the configure user add
command.

Procedure

Step 1 Use SSH to connect to the hostname or IP address of the management interface. Alternatively, you can connect
to the console port.
Step 2 At the login as: command prompt, enter your user name and press Enter.
Step 3 At the Password: prompt, enter your password and press Enter.
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.

Step 4 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

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD N/A CLI Basic

Configuration

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

Note On all devices, after a user makes three consecutive failed attempts to log into the CLI or shell via SSH, the
system terminates the SSH connection.

Firepower Management Center Configuration Guide, Version 6.3

28
Your User Account
Logging Into the Command Line Interface on FTD 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 1105 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.

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.

Firepower Management Center Configuration Guide, Version 6.3

29
 Your User Account
Viewing Basic System Information in the Web Interface

Viewing Basic System Information in the Web Interface

Smart License Classic License Supported Devices Supported Domains Access

N/A Any Any Any Any

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.

Switching Domains on the Firepower Management Center

Smart License Classic License Supported Device Supported Domains Access

N/A Any FMC Any Any

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.

Firepower Management Center Configuration Guide, Version 6.3

30
 Your User Account
Logging Out of a Firepower System Web Interface

Logging Out of a Firepower System Web Interface

Smart License Classic License Supported Devices Supported Domains Access

N/A Any Any Any Any

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.

Procedure

From the drop-down list under your user name, choose Logout.

Related Topics
Session Timeout, on page 24

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.
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:

Firepower Management Center Configuration Guide, Version 6.3

31
 Your User Account
The Context Menu

• 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, using the Contextual
Cross-Launch feature. For more information, see Event Investigation Using Web-Based Resources,
on page 2353.
• (If your organization has deployed Cisco Security Packet Analyzer) Explore packets related to the
event. For details, see Event Investigation Using Cisco Security Packet Analyzer, on page 2347.

While viewing connection events, you can add items to the default Security Intelligence whitelists and
blacklists:
• 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.

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.

Firepower Management Center Configuration Guide, Version 6.3

32
 Your User Account
History for Logging into the Firepower System

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 398

History for Logging into the Firepower System

Feature Version Details

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.

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.

Supported platforms: FMC

Firepower Management Center Configuration Guide, Version 6.3

33
 Your User Account
History for Logging into the Firepower System

Firepower Management Center Configuration Guide, Version 6.3

34
 CHAPTER 3
Specifying User Preferences
The following topics describe how to specify user preferences:
• User Preferences Introduction, on page 35
• Changing Your Password, on page 35
• Changing an Expired Password, on page 36
• Specifying Your Home Page, on page 36
• Configuring Event View Settings, on page 37
• Setting Your Default Time Zone, on page 41
• Specifying Your Default Dashboard, on page 42

User Preferences Introduction

You can configure the preferences that are tied to a single user account, such as the home page, account
password, time zone, dashboard, and event viewing preferences.
Depending on your user role, you can specify certain preferences for your user account, including passwords,
event viewing preferences, time zone settings, and home page preferences.
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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Any

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.
If password strength checking is enabled, passwords must be at least eight alphanumeric characters of mixed
case and must include at least one numeric character. Passwords cannot be a word that appears in a dictionary
or include consecutive repeating characters.
If you are an LDAP or a RADIUS user, you cannot change your password through the web interface.

Firepower Management Center Configuration Guide, Version 6.3

35
 Your User Account
Changing an Expired Password

Procedure

Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Enter your Current Password, and click Change.
Step 3 In the New Password and Confirm fields, enter your new password.
Step 4 Click Change.

Changing an Expired Password

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Any

Depending on the settings for your user account, your password may expire. Note that the password expiration
time period is set when your account is created and cannot be changed. 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 If password strength checking is enabled, passwords must be at least eight alphanumeric
characters of mixed case and must include at least one numeric character. Passwords cannot
be a word that appears in a dictionary or include consecutive repeating characters.

• Click Skip to change your password later.

Specifying Your Home Page

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Any except External

Database user

You can specify a page within the web interface as your home page for the appliance. The default home page
is the Summary Dashboard (Overview > Dashboards), except for user accounts with no dashboard access.
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.

Firepower Management Center Configuration Guide, Version 6.3

36
 Your User Account
Configuring Event View Settings

Procedure

Step 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click Home Page.
Step 3 Choose the page you want to use as your home page from the drop-down list.
The options in the drop-down list are based on the access privileges for your user account. For more information,
see Web Interface User Roles, on page 45.

Step 4 Click Save.

Configuring Event View Settings

Smart License Classic License Supported Device Supported Domains Access

Any Any Any Any feature dependent

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 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click Event View Settings.
Step 3 In the Event Preferences section, configure the basic characteristics of event views; see Event View
Preferences, on page 37.
Step 4 In the File Preferences section, configure file download preferences; see File Download Preferences, on page
39.
Step 5 In the Default Time Windows section, configure the default time window or windows; see Default Time
Windows, on page 39.
Step 6 In the Default Workflow sections, configure default workflows; see Default Workflows, on page 41.
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:

Firepower Management Center Configuration Guide, Version 6.3

37
 Your User Account
Event View Preferences

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

Firepower Management Center Configuration Guide, Version 6.3

38
 Your User Account
File Download Preferences

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

Firepower Management Center Configuration Guide, Version 6.3

39
 Your User Account
Default Time Windows

• The Health Monitoring Time Window sets the default time window for health events.

You can only set time windows for event types your user account can access. All user types can set event
time windows. Administrators, Maintenance Users, and Security Analysts can set health monitoring time
windows. Administrators and Maintenance Users can set audit log time windows.
Note that because not all event views can be constrained by time, time window settings have no effect on
event views that display hosts, host attributes, applications, clients, vulnerabilities, user identity, or white list
violations.
You can either use Multiple time windows, one for each of these types of events, or you can use a Single
time window that applies to all events. If you use a single time window, the settings for the three types of
time window disappear and a new Global Time Window setting appears.
There are three types of time window:
• static, which displays all the events generated from a specific start time to a specific end time
• expanding, which displays all the events generated from a specific start time to the present; as time moves
forward, the time window expands and new events are added to the event view
• sliding, which displays all the events generated from a specific start time (for example, one day ago) to
the present; as time moves forward, the time window “slides” so that you see only the events for the
range you configured (in this example, for the last day)

The maximum time range for all time windows is from midnight on January 1, 1970 (UTC) to 3:14:07 AM
on January 19, 2038 (UTC).
The following options appear in the Time Window Settings drop-down list:
• The Show the Last - Sliding option allows you configure a sliding default time window of the length
you specify.
The appliance displays all the events generated from a specific start time (for example, 1 hour ago) to
the present. As you change event views, the time window “slides” so that you always see events from
the last hour.
• The Show the Last - Static/Expanding option allows you to configure either a static or expanding
default time window of the length you specify.
For static time windows, enable the Use End Time check box. The appliance displays all the events
generated from a specific start time (for example, 1 hour ago) to the time when you first viewed the
events. As you change event views, the time window stays fixed so that you see only the events that
occurred during the static time window.
For expanding time windows, disable the Use End Time check box. The appliance displays all the
events generated from a specific start time (for example, 1 hour ago) to the present. As you change event
views, the time window expands to the present time.
• The Current Day - Static/Expanding option allows you to configure either a static or expanding default
time window for the current day. The current day begins at midnight, based on the time zone setting for
your current session.
For static time windows, enable the Use End Time check box. The appliance displays all the events
generated from midnight to the time when you first viewed the events. As you change event views, the
time window stays fixed so that you see only the events that occurred during the static time window.

Firepower Management Center Configuration Guide, Version 6.3

40
 Your User Account
Default Workflows

For expanding time windows, disable the Use End Time check box. The appliance displays all the
events generated from midnight to the present. As you change event views, the time window expands to
the present time. Note that if your analysis continues for over 24 hours before you log out, this time
window can be more than 24 hours.
• The Current Week - Static/Expanding option allows you to configure either a static or expanding
default time window for the current week. The current week begins at midnight on the previous Sunday,
based on the time zone setting for your current session.
For static time windows, enable the Use End Time check box. The appliance displays all the events
generated from midnight to the time when you first viewed the events. As you change event views, the
time window stays fixed so that you see only the events that occurred during the static time window.
For expanding time windows, disable the Use End Time check box. The appliance displays all the
events generated from midnight Sunday to the present. As you change event views, the time window
expands to the present time. Note that if your analysis continues for over 1 week before you log out, this
time window can be more than 1 week.

Default Workflows
A workflow is a series of pages displaying data that analysts use to evaluate events. For each event type, the
appliance ships with at least one predefined workflow. For example, as a Security Analyst, depending on the
type of analysis you are performing, you can choose among ten different intrusion event workflows, each of
which presents intrusion event data in a different way.
The appliance is configured with a default workflow for each event type. For example, the Events by Priority
and Classification workflow is the default for intrusion events. This means whenever you view intrusion
events (including reviewed intrusion events), the appliance displays the Events by Priority and Classification
workflow.
You can, however, change the default workflow for each event type. The default workflows you are able to
configure depend on your user role. For example, intrusion event analysts cannot set default discovery event
workflows.

Setting Your Default Time Zone

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Any

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.
You can change the time zone used to display events from the standard UTC time that the appliance uses.
When you configure a time zone, it applies only to your user account and is in effect until you make further
changes to the time zone.

Firepower Management Center Configuration Guide, Version 6.3

41
 Your User Account
Specifying Your Default Dashboard

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 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click the Time Zone Preference tab.
Step 3 From the left list box, choose the continent or area that contains the time zone you want to use.
Step 4 From the right list box, choose the zone (city name) that corresponds with the time zone you want to use.
Step 5 Click Save.

Specifying Your Default Dashboard

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint/Any

Security Analyst

The default dashboard appears when you choose Overview > Dashboards. Unless changed, the default
dashboard for all users is the Summary dashboard.
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 1 From the drop-down list under your user name, choose User Preferences.
Step 2 Click Dashboard Settings.
Step 3 Choose the dashboard you want to use as your default from the drop-down list. If you choose None, when
you select Overview > Dashboards, you can then choose a dashboard to view.
Step 4 Click Save.

Related Topics
Viewing Dashboards, on page 237

Firepower Management Center Configuration Guide, Version 6.3

42
 CHAPTER 4
User Accounts for Management Access
The Firepower Management Center and managed devices include a default admin account for management
access. This chapter discusses how to create custom user accounts for supported models. See Logging into
the Firepower System, on page 19 for detailed information about logging into the Firepower Management
Center or a managed device with a user account.
This chapter also describes Cisco Security Manager (CSM) single sign-on when you manage an ASA with
CSM and the FirePOWER services module with the Firepower Management Center.
• About User Accounts, on page 43
• Prerequisites and Requirements for User Accounts, on page 46
• Guidelines and Limitations for User Accounts, on page 47
• Add an Internal User Account, on page 47
• Configure External Authentication, on page 51
• Customize User Roles for the Web Interface, on page 68
• Configure Cisco Security Manager Single Sign-on, on page 72
• Troubleshooting LDAP Authentication Connections, on page 73
• History for User Accounts, on page 75

About User Accounts

You can add custom user accounts on the Firepower Management Center and on managed devices, either as
internal users or, if supported for your model, as external users on a LDAP or RADIUS server. Each Firepower
Management Center and each managed device maintains separate user accounts. For example, when you add
a user to the Firepower Management Center, 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

Firepower 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 Account, on page 47.
• 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 51.

Firepower Management Center Configuration Guide, Version 6.3

43
 Your User Account
Web Interface, CLI, or Shell Access

Web Interface, CLI, or Shell Access

When you configure user accounts, you enable web interface access and CLI or shell access separately.
Firepower devices include a Firepower CLI that runs on top of Linux. CLI users can also access the Linux
shell under TAC supervision. For detailed information about the management UIs, see User Interfaces in
Firepower Management Center Deployments, on page 21.

Caution On all devices, users with CLI or shell access can obtain sudoers privileges in the 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/shell access
appropriately.
• When granting CLI access privileges, restrict the list of users with Config level access.
• Do not add users directly in the shell; only use the procedures in this chapter.
• Do not access Firepower devices using the shell or CLI expert mode unless directed by Cisco TAC.

Each device type supports different forms of access as detailed here:

• For FTD, ASA FirePOWER, and NGIPSv, CLI access is available for direct management of the device.
• You can create internal users on these devices using the CLI.
• You can establish external users on Firepower Threat Defense devices.
• Users who log into these devices through the management interface access the CLI. Under TAC
supervision users can access the shell using the expert command.

• The Firepower Management Center has a web interface, a CLI, and Linux shell for direct management
of the device.
• The Firepower Management Center supports two different internal admin users: one for the web
interface, and another with CLI or shell access. These two admin users are different accounts and
do not share the same password. (To change the password for the web interface admin, use System >
Users > Users. To change the password for the CLI/shell admin, use the FMC CLI command
configure password.)
• Firepower Management Center internal users added in the web interface other than admin have
web interface access only.
• You can grant CLI or shell access to Firepower Management Center external users.
• On the Firepower Management Center by default, when any account with shell or CLI access logs
in to the management interface, it directly accesses the Linux shell. When you enable the Firepower
Management Center CLI, these users first gain access to the CLI on logging in and may gain access
to the shell with the expert command. See Firepower Management Center Command Line Reference,
on page 2753

• 7000 and 8000 Series devices have both a web interface and a CLI for direct management of the device.
• 7000 and 8000 Series device internal users have web interface and CLI access.
• You can enable CLI or shell access for 7000 and 8000 Series device external users.

Firepower Management Center Configuration Guide, Version 6.3

44
 Your User Account
User Roles

• Users who log into these devices through the management interface access the CLI. Under TAC
supervision, users with Config level access can access the shell using the expert command.

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.

Web Interface User Roles

The 7000 and 8000 Series devices have access to the following user roles: Administrator, Maintenance User,
and Security Analyst.
The Firepower Management Center includes the following predefined 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
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.

Firepower Management Center Configuration Guide, Version 6.3

45
 Your User Account
CLI User Roles

Security Analyst
Provides access to security event analysis features, and read-only access to health events, in the Overview,
Analysis, Health, and System menus.
Security Analyst (Read Only)
Provides read-only access to security event analysis features and health event features in the Overview,
Analysis, Health, and System menus.
Security Approver
Provides limited access to access control and associated policies and network discovery policies in the
Policies menu. Security Approvers can view and deploy these policies, but cannot make policy changes.
Threat Intelligence Director (TID) User
Provides access to Threat Intelligence Director configurations in the Intelligence menu. Threat Intelligence
Director (TID) Users can view and configure TID.
The 7000 and 8000 Series devices have access to 3 of these predefined user roles: Administrator, Maintenance
User, and Security Analyst.

CLI User Roles

User access to commands in the CLI depends on the role you assign.

Note CLI users on the FMC do not have a user role; they can use all available commands.

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.

Note External CLI users always have the Config user role.

Prerequisites and Requirements for User Accounts

Model Support
External user authentication is supported for the following models:
• Firepower Management Center
• Firepower Threat Defense

Firepower Management Center Configuration Guide, Version 6.3

46
 Your User Account
Guidelines and Limitations for User Accounts

• 7000 and 8000 Series

Guidelines and Limitations for User Accounts

Defaults
All devices include an admin user as a local user account for all forms of access; you cannot delete the admin
user. The default password is Admin123.

Global Settings
By default the following settings apply to all user accounts on the Firepower Management Center:
• 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.

You can change these settings for all users as a system configuration. (System > Configuration) See Global
User Configuration Settings, on page 1050.

Add an Internal User Account

Each device maintains separate user accounts. The Firepower Management Center and 7000 and 8000 Series
have similar web interfaces. For the Firepower Threat Defense, NGIPSv, and ASA FirePOWER, you must
add internal users at the CLI. You cannot add users at the CLI on the Firepower Management Center and 7000
and 8000 Series.

Add an Internal User at the Web Interface

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Administrator

7000 & 8000 Series

This procedure describes how to add custom internal user accounts at the web interface of a Firepower
Management Center or 7000 & 8000 Series device.
The System > Users > Users tab 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 Firepower Management Center, 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.

Firepower Management Center Configuration Guide, Version 6.3

47
 Your User Account
Add an Internal User at the Web Interface

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 1135.
When you add a user in a leaf domain, that user is not visible from the global domain.

Procedure

Step 1 Choose System > Users.

The Users tab shows by default.

Step 2 Click Create User.

Step 3 Enter a User Name.
Step 4 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 5 Enter values in the Password and Confirm Password fields.
The values must conform to the password options you set for this user.

Step 6 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 7 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 8 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 9 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 10 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. A strong password must be at least eight
alphanumeric characters of mixed case and must include at least 1 numeric character and 1 special
character. It cannot be a word that appears in a dictionary or include consecutive repeating characters.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

48
 Your User Account
Add an Internal User at the CLI

Step 11 (7000 or 8000 Series) Assign the appropriate level of Command-Line Interface Access as described in CLI
User Roles, on page 46.
Note Unlike for the 7000 or 8000 Series, you cannot enable shell access for Firepower Management
Center internal users (other than the default admin user); you can, however, enable shell access for
external users.

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 68.
For external users, if the user role is assigned through group or list membership, you cannot remove the
minimum access rights. You can, however, assign additional rights. If the user role is the default user role
that you set on the device, then you can modify the role in the user account without limitations. When you
modify the user role, the Authentication Method column on the Users tab provides a status of External -
Locally Modified.
The options you see depend on whether the device is in a single domain or multidomain (Firepower Management
Center only) deployment.
• Single domain—Check the user role(s) you want to assign the user.
• Multidomain (Firepower Management Center only)—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:
1. Click Add Domain.
2. Choose a domain from the Domain drop-down list.
3. Check the user roles you want to assign the user.
4. Click Save.

Step 13 Click Save.

Add an Internal User at the CLI

Smart License Classic License Supported Devices Supported Domains Access

Any Any FTD Any Config

ASA FirePOWER
NGIPSv

Use the CLI to create internal users on the FTD, ASA FirePOWER, and NGIPSv devices. These devices do
not have a web interface, so internal (and external) users can only access the CLI for management.

Firepower Management Center Configuration Guide, Version 6.3

49
 Your User Account
Add an Internal User at the CLI

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}
You can define the user with the following privilege levels:
• config—Gives the user configuration access. This role gives the user full administrator rights to all
commands.
• basic—Gives the user basic access. This role does not allow the user to enter configuration commands.

Example:
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

Firepower Management Center Configuration Guide, Version 6.3

50
 Your User Account
Configure External Authentication

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

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

About External Authentication

When you enable external authentication for management users, the device verifies the user credentials with
an LDAP or RADIUS server as specified in an external authentication object.
External authentication objects can be used by the Firepower Management Center, 7000 and 8000 Series, and
FTD devices. You can share the same object between all 3 types, or create separate objects.
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

Firepower Management Center Configuration Guide, Version 6.3

51
 Your User Account
External Authentication for the Firepower Management Center and 7000 and 8000 Series

managed device usage. For the 7000 and 8000 Series and 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/shell users in the external authentication object. For
CLI/shell 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/shell access that is also configured for CAC authentication.

Note Users with CLI/shell access with the Config user role have root privileges in the shell, which can present a
security risk; all external CLI/shell users have Config access. Make sure that you restrict the list of users with
CLI/shell access appropriately. Cisco strongly recommends that you do not establish additional CLI/shell
users on the Firepower Management Center.

External Authentication for the Firepower Management Center and 7000 and 8000 Series
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 or shell access. If you have more than one external
authentication object enabled, then users can authenticate using only the first object in the list. External CLI
users on 7000 or 8000 Series devices always have Config privileges; other user roles are not supported.

External Authentication for the Firepower Threat Defense

For the FTD, you can only activate one external authentication object.
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.
External users always have Config privileges; other user roles are not supported.

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

52
 Your User Account
Add an LDAP External Authentication Object

Add an LDAP External Authentication Object

Smart License Classic License Supported Devices Supported Domains Access

Any Any FTD Any Administrator

7000 and 8000
Series
FMC

Add an LDAP server to support external users for device management.

For the FTD, only a subset of fields are used for CLI access. See Configure External Authentication for SSH,
on page 1095 for details about which fields are used.
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
Configure Management Interfaces, on page 1011 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 1 Choose System > Users.

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
66 to fully configure CAC authentication and authorization. You cannot use this object for CLI/shell 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,
Shell 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.

Firepower Management Center Configuration Guide, Version 6.3

53
 Your User Account
Add an LDAP External Authentication Object

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
NewYork for that attribute, to retrieve only users in the New York office, enter
(physicalDeliveryOfficeName=NewYork).
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. 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.

• User Name Template—Provide a template that corresponds with your UI Access Attribute. For
example, to authenticate all users who work in the Security organization of the Example company
by connecting to an OpenLDAP server where the UI access attribute is uid, you might enter
uid=%s,ou=security,dc=example,dc=com in the User Name Template field. For a Microsoft Active
Directory server, you could enter %[email protected].
This field is required for CAC authentication.
• Timeout—Enter the number of seconds before rolling over to the backup connection. The default
is 30.

Step 12 (Optional) Configure Attribute Matching 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,
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.

Firepower Management Center Configuration Guide, Version 6.3

54
Your User Account
Add an LDAP External Authentication Object

This field is required for CAC authentication.

• Set the Shell Access Attribute if you want to use a shell access attribute other than the user distinguished
type. For example, on a Microsoft Active Directory Server, use the sAMAccountName shell access attribute
to retrieve shell 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 Shell Access Filter to allow CLI/shell users.
To prevent LDAP authentication of shell access, leave this field blank. To specify CLI/shell users, choose
one of the following methods:
• To use the same filter you specified when configuring authentication settings, choose Same as Base
Filter.

Firepower Management Center Configuration Guide, Version 6.3

55
 Your User Account
Add an LDAP External Authentication Object

• To retrieve administrative user entries based on attribute value, enter the attribute name, a comparison
operator, and the attribute value you want to use as a filter, enclosed in parentheses. For example, if all
network administrators have a manager attribute which has an attribute value of shell, you can set a
base filter of (manager=shell).

Note The names 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.

Note For the 7000 or 8000 Series and the Firepower Management Center, remove any internal users that
have the same user name as users included in the Shell Access Filter. For the Firepower Management
Center, the only internal shell user is admin, so do not also create an admin external user.
For the FTD, 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 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 73.

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:
• Firepower Management Center—Enable External Authentication for Users on the Firepower Management
Center, on page 65
• FTD—Configure External Authentication for SSH, on page 1095
• 7000 and 8000 Series—External Authentication Settings, on page 1080

Step 19 If you later add or delete users on the LDAP server, you must refresh the user list and redeploy the Platform
Settings for managed devices. This step is not required for the Firepower Management Center.

Firepower Management Center Configuration Guide, Version 6.3

56
Your User Account
Add an LDAP External Authentication Object

a) Click the refresh icon ( ) 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) For 7000 and 8000 Series devices, make a small configuration change in the Platform Settings so that the
settings are marked as Out-of-Date. 7000 and 8000 Series Platform Settings are not automatically marked
as Out-of-Date for LDAP shell user list updates.
Note that the Firepower Theat Defense Platform Setttings are automatically marked as Out-of-Date, so
you do not need to perform this workaround.
c) Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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.

Firepower Management Center Configuration Guide, Version 6.3

57
 Your User Account
Add an LDAP External Authentication Object

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 Shell Access Attribute of sAMAccountName causes each sAMAccountName attribute to
be checked for all objects in the directory for matches when a user logs into a shell or 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
Microsoft Active Directory Server. The LDAP server in this example has an IP address of 10.11.3.4.
The connection uses port 636 for access.

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. 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.

Firepower Management Center Configuration Guide, Version 6.3

58
Your User Account
Add an LDAP External Authentication Object

The connection to the server is encrypted using SSL and a certificate named certificate.pem is
used for the connection. In addition, connections to the server time out after 60 seconds because of
the Timeout setting.
Because this server is a Microsoft Active Directory server, it uses the sAMAccountName attribute to
store user names rather than the uid attribute. Note that the configuration includes a UI Access
Attribute of sAMAccountName. As a result, the Firepower System checks the sAMAccountName attribute
for each object for matching user names when a user attempts to log into the Firepower System.
In addition, a Shell Access Attribute of sAMAccountName causes each sAMAccountName attribute to
be checked for all objects in the directory for matches when a user logs into a shell 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.

Firepower Management Center Configuration Guide, Version 6.3

59
 Your User Account
Add a RADIUS External Authentication Object

The shell access filter is set to be the same as the base filter, so the same users can access the appliance
through the shell or CLI as through the web interface.

Add a RADIUS External Authentication Object

Smart License Classic License Supported Devices Supported Domains Access

Any Any FTD Any Administrator

7000 and 8000
Series
FMC

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

For the FTD, only a subset of fields are used for CLI access. See Configure External Authentication for SSH,
on page 1095 for details about which fields are used.
In a multidomain deployment, external authentication objects are only available in the domain in which they
are created.

Firepower Management Center Configuration Guide, Version 6.3

60
Your User Account
Add a RADIUS External Authentication Object

Procedure

Step 1 Choose System > Users.

Step 2 Click the External Authentication tab.
Step 3 Click Add External Authentication Object.
Step 4 Set the Authentication Method to RADIUS.
Step 5 Enter a Name and optional Description.
Step 6 For the Primary Server, enter a Host Name/IP Address.
Step 7 (Optional) Change the Port from the default.
Step 8 Enter the RADIUS Secret Key.
Step 9 (Optional) Enter the Backup Server parameters.
Step 10 (Optional) Enter RADIUS-Specific Parameters.
a) Enter the Timeout in seconds before retrying the primary server. The default is 30.
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.

Firepower Management Center Configuration Guide, Version 6.3

61
 Your User Account
Add a RADIUS External Authentication Object

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 Shell Access Filter area Administrator Shell Access User List field, enter the user names
that should have shell access, separated by commas.
Make sure that these usernames match usernames on the RADIUS server. The names 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.
To prevent RADIUS authentication of shell access for , leave the field blank.
Note For the 7000 or 8000 Series and the Firepower Management Center, remove any internal users that
have the same user name as users included in the shell access filter. For the Firepower Management
Center, the only internal shell user is admin, so do not also create an admin external user.
For the FTD, 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 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.

Step 13 (Optional) Click Test to test connectivity to the RADIUS 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.

Step 14 (Optional) You can also enter Additional Test Parameters to test user credentials for a user who should be
able to authenticate: enter a User Name and Password, and then click Test.
Tip If you mistype the name or password of the test user, the test fails even if the server configuration
is correct. To verify that the server configuration is correct, click Test without entering user
information in the Additional Test Parameters field first. If that succeeds, supply a user name and
password to test with the specific user.

Example:

Firepower Management Center Configuration Guide, Version 6.3

62
Your User Account
Add a RADIUS External Authentication Object

To test if you can retrieve the JSmith user credentials at the Example company, enter JSmith and the correct
password.

Step 15 Click Save.

Step 16 Enable use of this server:
• Firepower Management Center—Enable External Authentication for Users on the Firepower Management
Center, on page 65
• FTD—Configure External Authentication for SSH, on page 1095
• 7000 and 8000 Series—External Authentication Settings, on page 1080

Examples
Simple User Role Assignments
The following figure illustrates a sample RADIUS login authentication object for a server running
FreeRADIUS with an IP address of 10.10.10.98. Note that the connection uses port 1812 for access,
and note that connections to the server time out after 30 seconds of disuse, then retry three times
before attempting to connect to a backup authentication server.
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 shell account.
The following graphic depicts the role configuration for the example:

Firepower Management Center Configuration Guide, Version 6.3

63
 Your User Account
Add a RADIUS External Authentication Object

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 FreeRADIUS 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.

Firepower Management Center Configuration Guide, Version 6.3

64
 Your User Account
Enable External Authentication for Users on the Firepower Management Center

EnableExternalAuthenticationforUsersontheFirepowerManagementCenter
Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

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

Before you begin

Add 1 or more external authentication objects according to Add an LDAP External Authentication Object ,
on page 53 and Add a RADIUS External Authentication Object, on page 60.

Firepower Management Center Configuration Guide, Version 6.3

65
 Your User Account
Enable External Authentication for Users on Managed Devices

Procedure

Step 1 Choose System > Users.

Step 2 Click the External Authentication tab.
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 ( ) next to the each external authentication object that you want to use. If you enable
more than 1 object, then users are compared against servers in the order specified. See the next step to reorder
servers.
If you enable shell authentication, you must enable an external authentication object that includes a Shell
Access Filter. Also, CLI or shell access users can only authenticate against the server whose authentication
object is highest in the list.

Step 5 (Optional) Drag and drop servers to change the order in which authentication they are accessed when an
authentication request occurs.
Step 6 Choose Shell Authentication > Enabled if you want to allow CLI or shell 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 or shell access.

Step 7 Click Save and Apply.

Enable External Authentication for Users on Managed Devices

Enable External Authentication in the Platform Settings, and then deploy the settings to the managed devices.
See the following procedures for your managed device type:
• Firepower Threat Defense—Configure External Authentication for SSH, on page 1095
• 7000 and 8000 Series—External Authentication Settings, on page 1080

Configure Common Access Card Authentication with LDAP

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Administrator

7000 and 8000 Network Admin
Series

Firepower Management Center Configuration Guide, Version 6.3

66
Your User Account
Configure Common Access Card Authentication with LDAP

If your organization uses Common Access Cards (CACs), you can configure LDAP authentication to
authenticate FMC or 7000 and 8000 Series 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.

Step 2 Direct your browser to https://ipaddress_or_hostname/, where ipaddress or hostname corresponds to your
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 , on page 53. You must configure the following:
• CAC checkbox.
• LDAP-Specific Parameters > Show Advanced Options > User Name Template.
• Attribute Mapping > UI Access Attribute.

Step 8 Click Save.

Step 9 Enable external authentication and CAC authentication as described in Enabling External Authentication to
Classic Devices, on page 1081 or Enable External Authentication for Users on the Firepower Management
Center, on page 65.
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 999.
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 1001 .

Firepower Management Center Configuration Guide, Version 6.3

67
 Your User Account
Customize User Roles for the Web Interface

Step 13 Log into the device according to Logging Into a 7000 or 8000 Series Device with CAC Credentials, on page
27 or Logging Into the Firepower Management Center with CAC Credentials, on page 26.

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 Web Interface User Roles,
on page 45.

Note CLI/shell user roles are limited to Config and Basic roles. See CLI User Roles, on page 46 for more information.

Create Custom User Roles

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Administrator

7000 & 8000 Series

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.

Procedure

Step 1 Choose System > Users.

Step 2 Click the User Roles tab.
Step 3 Add a new user role with one of the following methods:
• Click Create User Role.

• Click the copy icon ( ) next to the user role you want to copy.
• Import a custom user role from another device:

1. On the old device, click the export icon ( ) to save the role to your PC.
2. On the new device, choose System > Tools > Import/Export.
3. 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.

Firepower Management Center Configuration Guide, Version 6.3

68
 Your User Account
Create Custom User Roles

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 checkbox 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 70.
Step 9 Click Save.

Example
You can create custom user roles for access control-related features to designate whether users can
view and modify access control and associated policies.
The following table lists custom roles that you could create and user permissions granted for each
example. The table lists the privileges required for each custom role. In this example, Policy Approvers
can view (but not modify) access control and intrusion policies. They can also deploy configuration
changes to devices.

Table 1: Example 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

Firepower Management Center Configuration Guide, Version 6.3

69
 Your User Account
Deactivate User Roles

Deactivate User Roles

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Administrator

7000 & 8000 Series

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 1 Choose System > Users.

Step 2 Click the User Roles tab.
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

For the Firepower Management Center, 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 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 71. Only one user role at a time can be the escalation target role.
Step 2 Configure a Custom User Role for Escalation, on page 71.

Firepower Management Center Configuration Guide, Version 6.3

70
 Your User Account
Set the Escalation Target Role

Step 3 (For the logged in user) Escalate Your User Role, on page 72.

Set the Escalation Target Role

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Administrator

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 1 Choose System > Users.

Step 2 Click User Roles.
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

Smart License Classic License Supported Device Supported Domains Access

Any Any FMC Any Administrator

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.

Before you begin

Set a target user role according to Set the Escalation Target Role, on page 71.

Procedure

Step 1 Begin configuring your custom user role as described in Create Custom User Roles, on page 68.

Firepower Management Center Configuration Guide, Version 6.3

71
 Your User Account
Escalate Your User Role

Step 2 In the System Permissions area, choose the Set this role to escalate to: 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

Smart License Classic License Supported Device Supported Domains Access

Any Any FMC Any Any

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.

Configure Cisco Security Manager Single Sign-on

Smart License Classic License Supported Devices Supported Domains Access

Any Any ASA FirePOWER Any Administrator

Single sign-on enables integration between Cisco Security Manager (CSM) Version 4.7 or higher and the
Firepower Management Center, which allows you to access the Firepower Management Center from CSM

Firepower Management Center Configuration Guide, Version 6.3

72
 Your User Account
Troubleshooting LDAP Authentication Connections

without additional authentication to log in. When managing an ASA with the ASA FirePOWER module, you
may want to modify the policies deployed to the module. You can select the managing Firepower Management
Center in CSM and launch it in a web browser.

Note You cannot log in with single sign-on if your organization uses CACs for authentication.

Before you begin

• In NAT environments, the Firepower Management Center and CSM must reside on the same side of the
NAT boundary.

Procedure

Step 1 From CSM, generate a single sign-on shared encryption key that identifies the connection. See your CSM
documentation for more information.
Step 2 From the Firepower Management Center, choose System > Users.
Step 3 Choose CSM Single Sign-on.
Step 4 Enter the CSM hostname or IP address and the server Port.
Step 5 Enter the Shared key that you generated from CSM.
Step 6 (Optional) Click the Use Proxy For Connection check box if you want to use the Firepower Management
Center’s proxy server to communicate with CSM.
Step 7 Click Submit.
Step 8 Click Confirm Certificate to save the Certificate.

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.
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.

Firepower Management Center Configuration Guide, Version 6.3

73
 Your User Account
Troubleshooting LDAP Authentication Connections

• 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
shell access.
• If you used server type defaults, check that you have the correct server type and click Set Defaults
again to reset the default values.

• If you typed in your base distinguished name, click Fetch DNs to retrieve all the available base
distinguished names on the server, and select the name from the list.
• If you are using any filters, access attributes, or advanced settings, check that each is valid and typed
correctly.
• If you are using any filters, access attributes, or advanced settings, try removing each setting and testing
the object without it.
• If you are using a base filter or a shell access filter, make sure that the filter is enclosed in parentheses
and that you are using a valid comparison operator.
• To test a more restricted base filter, try setting it to the base distinguished name for the user to retrieve
just that user.
• If you are using an encrypted connection:
• Check that the name of the LDAP server in the certificate matches the host name that you use to
connect.
• Check that you have not used an IPv6 address with an encrypted server connection.

• If you are using a test user, make sure that the user name and password are typed correctly.
• If you are using a test user, remove the user credentials and test the object.
• Test the query you are using by connecting to the LDAP server and using this syntax:

ldapsearch -x -b 'base_distinguished_name'
-h LDAPserver_ip_address -p port -v -D
'user_distinguished_name' -W 'base_filter'

For example, if you are trying to connect to the security domain on myrtle.example.com using the
[email protected] user and a base filter of (cn=*), you could test the connection using
this statement:

ldapsearch -x -b 'CN=security,DC=myrtle,DC=example,DC=com'
-h myrtle.example.com -p 389 -v -D

Firepower Management Center Configuration Guide, Version 6.3

74
 Your User Account
History for User Accounts

'[email protected]' -W '(cn=*)'

If you can test your connection successfully but authentication does not work after you deploy a platform
settings policy, check that authentication and the object you want to use are both enabled in the platform
settings policy that is applied to the device.
If you connect successfully but want to adjust the list of users retrieved by your connection, you can add or
change a base filter or shell access filter or use a more restrictive or less restrictive base DN.

History for User Accounts

Feature Version Details

External Authentication for FTD SSH 6.2.3 You can now configure external
Access authentication for SSH access to the FTD
using LDAP or RADIUS.
New/Modified screens:
Devices > Platform Settings > External
Authentication
Supported platforms: FTD

Firepower Management Center Configuration Guide, Version 6.3

75
 Your User Account
History for User Accounts

Firepower Management Center Configuration Guide, Version 6.3

76
PA R T II
Firepower System Management
• Licensing the Firepower System, on page 79
• System Software Updates, on page 145
• Backup and Restore Introduction, on page 161
• Configuration Import and Export, on page 187
• Task Scheduling, on page 193
• FMC Database Purge, on page 213
 CHAPTER 5
Licensing the Firepower System
The following topics explain how to license the Firepower System.
• About Firepower Licenses, on page 79
• License Requirements for Firepower Management Center, on page 79
• Evaluation License Caveats, on page 80
• Smart vs. Classic Licenses, on page 80
• Licensing for Deployments with Firepower Threat Defense Devices (Smart Licensing), on page 81
• Licensing for All Other Firepower Devices (Classic Licensing), on page 119
• How to Convert a Classic License or PAK to a Smart License, on page 127
• Assign Licenses to Managed Devices from the Device Management Page, on page 129
• Firepower License and Service Subscription Expiration, on page 131
• Other Licensing Information in This Guide, on page 134
• Additional Information about Firepower Licensing, on page 135
• Cisco Success Network, on page 136
• End-User License Agreement, on page 142
• History for Licensing, on page 142

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.

License Requirements for Firepower Management Center

Firepower Management Center allows you to assign licenses to managed devices and manage licenses for the
system.
A hardware Firepower Management Center does not require purchase of additional licenses or service
subscriptions in order to manage devices.

Firepower Management Center Configuration Guide, Version 6.3

79
 Firepower System Management
Evaluation License Caveats

Note Firepower Management Center Virtual does have additional licensing requirements. See Firepower Management
Center Virtual Licenses, on page 88.

A single Firepower Management Center can manage both devices that require Classic licenses and devices
that require Smart Licenses.

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

While the licenses required for your managed devices are specific to your hardware, the type of licenses you
need (Smart or Classic) depends on the software product that runs on the device:

Software Product License Type

Firepower Management Center (hardware) FMC itself requires no license. It can simultaneously
manage devices with Smart and Classic licenses.

Firepower Management Center Virtual See Firepower Management Center Virtual Licenses,
on page 88.

Firepower Threat Defense Smart

Firepower Threat Defense Virtual

ASA with FirePOWER Services module Classic

Firepower NGIPS (hardware) Classic

Firepower NGIPS Virtual Classic

All other software products, including those that run See licensing information for your software product.
on Firepower hardware

Firepower Management Center Configuration Guide, Version 6.3

80
 Firepower System Management
Licensing for Deployments with Firepower Threat Defense Devices (Smart Licensing)

Important This documentation refers to devices by the software they run, irrespective of hardware model. For example,
a "Firepower Threat Defense device" is any hardware (or virtual) device that is running Firepower Threat
Defense software.
"NGFW" means different things to different people, so this documentation does not use this term.

Licensing for Deployments with Firepower Threat Defense

Devices (Smart Licensing)
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.

How to License Firepower Threat Defense Devices Managed by Firepower

Management Center
Firepower Threat Defense devices use Smart Licensing.

Procedure

Step 1 Verify that your Firepower deployment requires Smart Licenses.

See Smart vs. Classic Licenses, on page 80.
If your Firepower deployment does not use Smart Licenses, do not use the remainder of this topic. Instead,
see Licensing for All Other Firepower Devices (Classic Licensing), on page 119.
If your deployment needs both types of licenses, you can follow this document for devices that require Smart
Licensing, then follow the instructions under Licensing for All Other Firepower Devices (Classic Licensing),
on page 119 for devices that use Classic licensing.

Step 2 If you do not already have a Smart Account, create one.

It is recommended that 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 93.
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.

Firepower Management Center Configuration Guide, Version 6.3

81
 Firepower System Management
How to License Firepower Threat Defense Devices Managed by Firepower Management Center

Step 3 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 88.
(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 88.
You do not need to do anything to activate a base license, but many features require separate licensing,
which is discussed below.

Step 4 Understand the types of feature licenses (sometimes called service subscriptions) that your organization needs.
See Smart License Types and Restrictions, on page 86 and subtopics.

Step 5 Determine the number of feature licenses/service subscriptions that your organization needs.
• Generally, each managed device needs to be licensed for each feature you will use.
• For Firepower Management Centers in a high availability pair:
See FMC HA License Requirements, on page 479.
• 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 704.
• For clustered Firepower Threat Defense devices (intra- or inter-chassis clustering):
See Licenses for Clustering, on page 737.
(Clustering is available on Firepower 9300 and 4100 devices only.)
• For a multi-instance deployment:
See Licensing for Multi-Instance Deployments, on page 92.

Step 6 If you have existing licenses that you need to convert or move:
• To convert a Classic license to a license that can be used for Firepower Threat Defense:
See How to Convert a Classic License or PAK to a Smart License, on page 127.
• To transfer Smart Licenses that are currently registered to another Firepower Management Center:
See Transfer Smart Licenses to a Different Firepower Management Center, on page 117 and Deregister
a Firepower Management Center from the Cisco Smart Software Manager, on page 118.

Firepower Management Center Configuration Guide, Version 6.3

82
Firepower System Management
How to License Firepower Threat Defense Devices Managed by Firepower Management Center

• To move Smart Licenses that are currently registered to another Firepower Threat Defense device:
See Move or Remove Smart Licenses from Managed Devices, on page 117.

Step 7 If your Firepower system has restricted internet access:

Determine which solution is best for your situation:
• See Licensing Options for Air-Gapped Deployments, on page 98.
• 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:
Deploy a Smart Software Satellite Server. For information, see Smart Software Satellite Server Overview,
on page 99 and How to Deploy a Smart Software Satellite Server, on page 99.
• If your deployment is completely air-gapped and cannot connect to the licensing authority or to a satellite
server that connects to the licensing authority, or receive manual license updates:
See Specific License Reservation Overview, on page 101 and skip the rest of this procedure.

Step 8 If you have multiple Firepower Management Center appliances and you want to connect to Cisco's licensing
authority through a single proxy:
Deploy a Smart Software Satellite Server. For information, see Smart Software Satellite Server Overview, on
page 99.

Step 9 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 91.

Step 10 Purchase the licenses you need:

Contact your Cisco sales representative or authorized reseller.

Step 11 Verify that your reseller or Cisco sales representative has added your licenses to your Smart Account.
Look in Cisco Smart Software Manager (CSSM): https://software.cisco.com/#SmartLicensing-Inventory.
In CSSM, 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 12 After your virtual account (Smart Account) holds the licenses you expect, register your Firepower Management
Center to the Cisco Smart Software Manager (CSSM):
You must configure licensing in the Firepower Management Center using the web interface.
• If your Firepower Management Center connects directly to the CSSM:
See the following topics:
• Obtain a Product License Registration Token for Smart Licensing, on page 94 and
• Register Smart Licenses, on page 95

Firepower Management Center Configuration Guide, Version 6.3

83
 Firepower System Management
How to License Firepower Threat Defense Devices Managed by Firepower Management Center

• If your Firepower Management Center connects to a Smart Software Satellite Server:

See Configure the Connection to a Smart Software Satellite Server, on page 100.
• If your Firepower Management Center is completely isolated from the internet:
See Specific License Reservation Status, on page 109 and subtopics.

Step 13 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.

Step 14 If you have not yet done so, add your devices to the Firepower Management Center as managed devices.
See Add Devices to the Firepower Management Center, on page 499

Step 15 Assign licenses to your managed Firepower Threat Defense devices:

See Assign Licenses to Multiple Managed Devices, on page 114

Step 16 Verify that licenses have successfully been added to your devices.
See View Your Smart Licenses and Smart Licenses Status, on page 115.

Step 17 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 483.
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 737. Licensing steps are included in FMC: Add a Cluster, on page
747.

What to do next
• (Optional) If your Firepower Management Center needs to manage ASA with FirePOWER Services,
7000 or 8000 Series, or NGIPSv devices, configure licensing for those devices:
See Licensing for All Other Firepower Devices (Classic Licensing), on page 119.
• Understand validity periods and expiration. See Firepower License and Service Subscription Expiration,
on page 131.

Firepower Management Center Configuration Guide, Version 6.3

84
 Firepower System Management
Smart Software Manager

Smart Software Manager

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.
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 have either direct Internet access to the License Authority through
the Cisco Smart Software Manager or access through the Smart Software Satellite Server at scheduled time
periods. Normal license communication occurs every 30 days, but with the grace period, your appliance will
operate for up to 90 days without calling home. You must contact the License Authority before 90 days have
passed.
Optionally, you can configure a Smart Software Satellite Server to serve as a proxy for communicating with
the License Authority. For information, see Smart Software Satellite Server Overview, on page 99.

Service Subscriptions for Firepower Features (Smart Licensing)

Some features require a service subscription.

Firepower Management Center Configuration Guide, Version 6.3

85
 Firepower System Management
Smart License Types and Restrictions

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

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.

Smart 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 88.

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 89

Firepower Management Center Configuration Guide, Version 6.3

86
Firepower System Management
Smart License Types and Restrictions

License You Assign in Subscription You Duration Granted Capabilities

Firepower System Purchase

Malware • TM (Threat + Term-based AMP for Networks

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

• AMP For details, see Malware

Licenses for Firepower Threat
Defense Devices, on page 88.

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 89.

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 88.

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 91.

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 details, see VPN Licenses,
on page 124.

Firepower Management Center Configuration Guide, Version 6.3

87
 Firepower System Management
Base Licenses

Base Licenses
A base license is automatically included with every purchase of a Firepower Threat Defense or Firepower
Threat Defense Virtual device.
The Base license allows you to:
• configure your FTD devices to perform switching and routing (including DHCP relay and NAT)
• configure FTD devices as a high availability pair
• configure security modules as a cluster within a Firepower 9300 chassis (intra-chassis clustering)
• configure Firepower 9300 or Firepower 4100 series devices running Firepower Threat Defense as a
cluster (inter-chassis clustering)
• implement user and application control by adding user and application conditions to access control rules

Threat and malware detection and URL filtering features require additional, optional licenses.
Except in deployments using Specific License Reservation, Base licenses are automatically added to the
Firepower Management Center for every Firepower Threat Defense device you register.
For multi-instance deployments, see Licensing for Multi-Instance Deployments, on page 92.

Firepower Management Center Virtual Licenses

Generally, Firepower Management Center Virtual requires a license entitlement for each device that it will
manage.
If a Firepower Management Center Virtual appliance 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.)
In multi-instance deployments, you need one entitlement for each security module.
In standard, connected Smart Licensing, these licenses are perpetual.
In Specific Permanent Licensing, these licenses are term-based.
This entitlement appears in Cisco Smart Software Manager as Firepower MCv Device License with different
numbers of entitlements.

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.

Firepower Management Center Configuration Guide, Version 6.3

88
 Firepower System Management
Threat Licenses

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.

Threat Licenses
A Threat license allows you to perform intrusion detection and prevention, file control, and Security Intelligence
filtering:
• Intrusion detection and prevention allows you to analyze network traffic for intrusions and exploits and,
optionally, drop offending packets.
• File control allows you to detect and, optionally, block users from uploading (sending) or downloading
(receiving) files of specific types over specific application protocols. AMP for Networks, which requires
a Malware license, allows you to inspect and block a restricted set of those file types based on their
dispositions.
• Security Intelligence filtering allows you to blacklist—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 blacklist 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.

Firepower Management Center Configuration Guide, Version 6.3

89
 Firepower System Management
AnyConnect Licenses

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.
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.
The maximum 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

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

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 Smart License Types and Restrictions, on page 86.
You cannot deploy Remote Access VPN if the following are true:

Firepower Management Center Configuration Guide, Version 6.3

90
 Firepower System Management
Licensing for Export-Controlled Functionality

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

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 1102 and Configure
Remote Access VPN IPsec/IKEv2 Parameters, on page 902.

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 96
• If the option to use export-controlled functionality appears when you generate a new Product Instance
Registration Token in Cisco Smart Software Manager:

Firepower Management Center Configuration Guide, Version 6.3

91
 Firepower System Management
Licensing for High-Availability Configurations

• 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, on page 479
• For Firepower Threat Defense devices in a high-availability pair:
License Requirements for FTD Devices in a High Availability Pair, on page 704

See also the topics for specific license types under the Smart License Types and Restrictions, on page 86
topic.

Licensing for FTD Clusters

In addition to information in this Licensing chapter, see:
• Licenses for Clustering, on page 737
• FMC: Add a Cluster, on page 747.
•

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.

Firepower Management Center Configuration Guide, Version 6.3

92
 Firepower System Management
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
607.

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:

Firepower Management Center Configuration Guide, Version 6.3

93
 Firepower System Management
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 Managed by Firepower Management Center , on page
81

Smart Licensing with Direct Internet Access

For the end-to-end process, see How to License Firepower Threat Defense Devices Managed by Firepower
Management Center , on page 81

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 95 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 Licensing section.)
Step 3 Sign in to the Cisco Smart Software Manager.
Step 4 Click Inventory.
Step 5 Click General.
Step 6 Click New Token.

Firepower Management Center Configuration Guide, Version 6.3

94
 Firepower System Management
Register Smart Licenses

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 96.

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 95.

Register Smart Licenses

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Global only Admin

Defense

Register the Firepower Management Center with the Cisco Smart Software Manager.

Before you begin

• If you are using a Smart Software Satellite Server or Specific License Reservation, do not use this
procedure. Instead, see Configure the Connection to a Smart Software Satellite Server, on page 100 or
How to Implement Specific License Reservation, on page 101, respectively.
• Ensure that the Firepower Management Center can reach the Cisco Smart Software Manager (CSSM)
server at tools.cisco.com:443. For details, see the appendix of the Firepower Management Center
Configuration Guide. Managed devices do not need to contact CSSM.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

95
 Firepower System Management
Enabling the Export Control Feature (for Accounts Without Global Permission)

• Make sure each Firepower Management Center 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 94, 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 In the Firepower Management Center’s web interface, click Register.
Step 3 Paste the token you generated from the 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.

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.

Step 5 Click Apply Changes.

What to do next
• Add your Firepower Threat Defense devices to the Firepower Management Center; see Add Devices to
the Firepower Management Center, on page 499.
• Assign licenses to your Firepower Threat Defense devices; see Assign Licenses to Multiple Managed
Devices, on page 114.

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 91.

Before you begin

• Make sure that your deployment does not already support the export-controlled functionality.

Firepower Management Center Configuration Guide, Version 6.3

96
Firepower System Management
Enabling the Export Control Feature (for Accounts Without Global Permission)

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:

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 750, 1000, 1500, 1600

(3DES/AES)

Cisco FMC 2K Series Strong Encryption 2000, 2500, 2600

(3DES/AES)

Cisco FMC 4K Series Strong Encryption 3500,4000, 4500, 4600

(3DES/AES)

Procedure

Step 1 Choose System > Licenses > Smart Licenses .

Note If you see the Request Export Key button, 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.

Firepower Management Center Configuration Guide, Version 6.3

97
 Firepower System Management
Disabling the Export Control Feature (for Accounts without Global Permission)

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 96, you can disable this functionality using this
procedure.

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 options for licensing deployments in 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 Satellite Server 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 Satellite For more information, see Specific License
Server Overview, on page 99 Reservation Overview, on page 101

Firepower Management Center Configuration Guide, Version 6.3

98
 Firepower System Management
Smart Software Satellite Server Overview

Smart Software Satellite Server Overview

As described in Periodic Communication with the License Authority, on page 85, 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 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.)
• Your Firepower Management Center has permanent connectivity, but you want to manage your Smart
Licenses via a single connection from your network.

The Smart Software Satellite Server allows you to schedule synchronization or manually synchronize Smart
License authorization with the Smart Software Manager.
For more information about the Smart Software Satellite Server, see https://www.cisco.com/c/en/us/buy/
smart-accounts/software-manager-satellite.html.
An alternate solution for air-gapped networks is Specific License Reservation. For information, see Specific
License Reservation Overview, on page 101.

How to Deploy a Smart Software Satellite Server

Before you begin

If your network is air-gapped, determine whether a Smart Software Satellite Server or a Specific License
Reservation is the best solution for your deployment. For more information, see Smart Software Satellite
Server Overview, on page 99 and Specific License Reservation Overview, on page 101.

Procedure

Step 1 Deploy and set up a Smart Software Satellite Server.

See the Smart Software Manager Satellite User Guide, available from https://www.cisco.com/c/en/us/buy/
smart-accounts/software-manager-satellite.html.

Step 2 Connect the Firepower Management Center to the satellite, obtain a registration token, and register the
management center to the satellite.
See Configure the Connection to a Smart Software Satellite Server, on page 100.

Step 3 Add devices to be managed.

See Add Devices to the Firepower Management Center, on page 499.

Step 4 Assign licenses to managed devices

See Assign Licenses to Multiple Managed Devices, on page 114

Step 5 Synchronize the satellite to the Cisco Smart Software Management Server (CSSM).
See the Smart Software Manager Satellite User Guide you used above.

Step 6 Schedule ongoing synchronization times.

Firepower Management Center Configuration Guide, Version 6.3

99
 Firepower System Management
Configure the Connection to a Smart Software Satellite Server

Configure the Connection to a Smart Software Satellite Server

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Global only Admin

Defense

Before you begin

• Set up a Smart Software Satellite Server. For information, see How to Deploy a Smart Software Satellite
Server, on page 99.
• Make a note of the CN of the TLS/SSL certificate on your Satellite server.
• Verify that your FMC can reach your Smart Software Satellite Server. For example, verify that the FQDN
configured as the satellite server 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.

Procedure

Step 1 Choose System > Integration.

Step 2 Click the Smart Software Satellite tab.
Step 3 Select Connect to Cisco Smart Software Satellite Server.
Step 4 Enter the URL of your Smart Software Satellite Server, using the CN value you collected in the prerequisites
of this procedure, in the following format:
https://FQDN_or_hostname_of_Satellite/Transportgateway/services/DeviceRequestHandler
The FQDN or hostname must match the CN value of the certificate presented by the satellite.

Step 5 Add a new SSL Certificate and paste the certificate text that you copied in the prerequisites for this procedure.
Step 6 Click Apply.
Step 7 Select System > Licenses > Smart Licenses and click Register.
Step 8 Create a new token on the Smart Satellite Server.
Step 9 Copy the token.
Step 10 Paste the token into the form on the management center page.
Step 11 Click Apply Changes.
The management center is now registered to the Smart Software Satellite Server.

What to do next
Complete remaining steps in How to Deploy a Smart Software Satellite Server, on page 99.

Firepower Management Center Configuration Guide, Version 6.3

100
 Firepower System Management
Specific License Reservation Overview

Specific License Reservation Overview

You can use the Specific License Reservation feature to deploy Smart Licensing in an air-gapped network.
When Specific License Reservation is enabled, the Firepower Management Center reserves licenses from
your virtual account for a specified duration without accessing the Cisco Smart Software Manager or Smart
Software Satellite Server.
Your Firepower Management Center can also simultaneously manage devices that use standard Classic
licenses. However, those devices do not use Specific License Reservation.
Features that require access to the internet, such as URL Lookups or contextual cross-launch to public web
sites, will not work.
Cisco does not collect web analytics or telemetry data for deployments that use Specific License Reservation.
Related Topics:
• Best Practices for Specific License Reservation, on page 101
• Requirements for Specific License Reservation, on page 101
• How to Implement Specific License Reservation, on page 101
• Specific License Reservation Status, on page 109
• Update a Specific License Reservation, on page 107
• Deactivate and Return the Specific License Reservation, on page 111
• Troubleshoot Specific License Reservation, on page 113

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 102.

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 102

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 103

Firepower Management Center Configuration Guide, Version 6.3

101
 Firepower System Management
Prerequisites for Specific License Reservation

Do This More Information

Step 3 Enable Specific License Reservation using the Enable the Specific Licensing Menu Option, on
Firepower Management Center page 103

Step 4 Generate a Reservation Request Code from the Generate a Reservation Request Code from the
Firepower Management Center Firepower Management Center, on page 104
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 105
Smart Software Manager

Step 6 Enter the Reservation Authorization Code into Enter the Reservation Authorization Code into the
the Firepower Management Center Firepower Management Center, on page 106

Step 7 Assign Specific Licenses to managed Firepower Assign Specific Licenses to Managed Devices, on
Threat Defence devices page 106

Step 9 (Outside of your Firepower Management Maintain Your Air-Gapped Deployment, on page
Center) Schedule reminders for ongoing 160
maintenance tasks

Prerequisites for Specific License Reservation

• Set up your Smart Account.
See Create a Smart Account to Hold Your Licenses, on page 93.
• 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 118.
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 Smart License Types and Restrictions,
on page 86 and its subtopics, especially Firepower Management Center Virtual Licenses, on page 88.
• 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 91.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

102
 Firepower System Management
Verify that your Smart Account is Ready to Deploy Specific License Reservation

• Add managed devices to your Firepower Management Center. For instructions, see Add Devices to the
Firepower Management Center, on page 499. (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.

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 102.
• 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 necessary, click Inventory.

Step 3 Click the Licenses tab.
Step 4 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 5 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

Specific License Supported Devices Supported Domains Access

Any Firepower Management Global Only Admin

Center

This procedure changes the "Smart Licenses" menu option to "Specific Licenses" in Firepower Management
Center.

Firepower Management Center Configuration Guide, Version 6.3

103
 Firepower System Management
Generate a Reservation Request Code from the 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 in to the Firepower Management Center admin account. By default, this gives you access to the shell. If
the Firepower Management Center CLI is enabled, this gives you access to the command line interface.
Step 3 For a Firepower Management Center with the CLI enabled, enter the expert command to access the shell.
Step 4 Execute the following command to access the Specific License Reservation options:
sudo manage_slr.pl
Example:
admin@fmc63betaslr: ~$ sudo manage_slr.pl
Password:

**************** 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 shell.
Step 8 On a Firepower Management Center with the CLI enabled, type 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

Specific License Supported Devices Supported Domains Access

Any Firepower Management Global Only Admin

Center

Procedure

Step 1 If you are not already viewing the Specific License Reservation page, choose System > Licenses > Specific
Licenses.
Step 2 Click Generate.

Firepower Management Center Configuration Guide, Version 6.3

104
 Firepower System Management
Generate a Reservation Authorization Code from Cisco Smart Software Manager

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:

https://software.cisco.com/#SmartLicensing-Inventory

Step 2 If necessary, click Inventory.

(This page may display automatically.)

Step 3 Click the Licenses tab.

Step 4 Click License Reservation.
Step 5 Enter the code that you generated from Firepower Management Center into the Reservation Request Code
box.
Step 6 Click Next.
Step 7 Select Reserve a specific license.
Step 8 Scroll down to display the entire License grid.
Step 9 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 96.

Step 10 Click Next.

Step 11 Click Generate Authorization Code.
At this point, the license is now in use according to the Smart Software Manager.

Step 12 Download the Authorization Code in preparation for entering it into the Firepower Management Center.

Firepower Management Center Configuration Guide, Version 6.3

105
 Firepower System Management
Enter the Reservation Authorization Code into the Firepower Management Center

Enter the Reservation Authorization Code into the Firepower Management Center

Specific License Supported Devices Supported Domains Access

Any Firepower Management Global Only Admin

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 Authorization Code file (.txt).
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.

Assign Specific Licenses to Managed Devices

Specific License Supported Devices Supported Domains Access

Any Firepower Management Global Only Admin

Center

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.

Firepower Management Center Configuration Guide, Version 6.3

106
 Firepower System Management
Update a Specific License Reservation

• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Update a Specific License Reservation

Specific License Supported Devices Supported Domains Access

Any Firepower Management Global Only Admin

Center

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:
https://software.cisco.com/#SmartLicensing-Inventory
b) If necessary, click Inventory.
(This page may display automatically.)
c) Click the Product Instances tab.
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 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.

Firepower Management Center Configuration Guide, Version 6.3

107
 Firepower System Management
Update a Specific License Reservation

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 96.

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:

Firepower Management Center Configuration Guide, Version 6.3

108
 Firepower System Management
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 109 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 308.

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 160.
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.

Firepower Management Center Configuration Guide, Version 6.3

109
 Firepower System Management
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 91.

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 107.

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 107.

Firepower Management Center Configuration Guide, Version 6.3

110
 Firepower System Management
Deactivate and Return the Specific License Reservation

Deactivate and Return the Specific License Reservation

Specific License Supported Devices Supported Domains Access

Any Firepower Management Global Only Admin

Center

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 the Return SLR button.
The following figure shows the Return SLR button.

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:

Firepower Management Center Configuration Guide, Version 6.3

111
 Firepower System Management
Deactivate and Return the Specific License Reservation

https://software.cisco.com/#SmartLicensing-Inventory
b) If necessary, click Inventory.
(This page may display automatically.)
c) Click the Product Instances tab.
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 CLI:.
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. By default, this gives you access to the shell.
If the Firepower Management Center CLI is enabled, this gives you access to the command line interface.
c) For a Firepower Management Center with the CLI enabled, enter the expert command to access the 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) Type exit to exit the shell.
h) On a Firepower Management Center with the CLI enabled, type exit to exit the command line interface

Firepower Management Center Configuration Guide, Version 6.3

112
 Firepower System Management
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
Firepower Management Center.
In the Firepower Management Center web interface, the UUID for a Firepower Management Center is the
Product Instance value displayed on the System > Licenses > Specific Licenses page.

I 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 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 shell.
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 107.

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 111.

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 103.

Firepower Management Center Configuration Guide, Version 6.3

113
 Firepower System Management
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 shell (see Enable the Specific Licensing Menu Option, on page 103), then refresh the Firepower Management
Center web interface. Your Return Code will be displayed.

Assign Licenses to Multiple Managed Devices

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Global only Admin

Defense

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 Smart Licenses or Specific Licenses 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
Devices to the Firepower Management Center, on page 499.
• Prepare licenses for distribution to managed devices: See Register Smart Licenses, on page 95

Procedure

Step 1 Choose System > Licenses > Smart Licenses or Specific Licenses.
Step 2 Click Edit Licenses.
Step 3 For each type of license you want to add to a device:
a) Click the tab for that type of license.
b) Click a device in the list on the left.
c) Click Add to move that device to the list on the right.
d) Repeat for each device to receive that type of license.
For now, don't worry about whether you have licenses for all of the devices you want to add.

Firepower Management Center Configuration Guide, Version 6.3

114
 Firepower System Management
View Your Smart Licenses and Smart Licenses Status

e) Repeat this subprocedure for each type of license you want to add.
f) Click Apply.

What to do next
• Verify that your licenses are correctly installed. Follow the procedure in View Your Smart Licenses and
Smart Licenses Status, on page 115.
• If export-controlled functionality is newly enabled, reboot each device. If devices are configured in a
high-availability pair, reboot both devices at the same time to avoid an Active-Active condition.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

View Your Smart Licenses and Smart Licenses Status

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Global only Admin

Defense

Use the Smart Licenses page to view the Smart Licenses for a Firepower Management Center and its managed
Firepower Threat Defense devices. 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 232 and Dashboard Widget Availability by User Role, on
page 219 and The Product Licensing Widget, on page 228.
• 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 1 Choose System > Licenses > Smart Licenses.

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 it ( ) in the License Status
column.
Note If you see duplicate Firepower Management Center Virtual licenses, each represents one managed
device.

Firepower Management Center Configuration Guide, Version 6.3

115
 Firepower System Management
Smart License Status

If all devices show a green circle with a check mark ( ), your devices are properly licensed and ready to
use.

If you see any License Status other than a green circle with a check mark ( ), hover over the status icon to
view the message.

What to do next

• If you had any devices that did NOT have a green circle with a check mark ( ), you may need to
purchase more licenses.

Smart License Status

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:
• — All licenses assigned to managed devices are in compliance and the Firepower Management Center
is communicating successfully with the Cisco licensing authority.
• — Device licenses are in compliance, but the Firepower Management Center is not able to communicate
with the Cisco licensing 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 91.

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

Firepower Management Center Configuration Guide, Version 6.3

116
 Firepower System Management
Move or Remove Smart Licenses from Managed Devices

unused available features so that you can maximize the value of the product in your network. See Cisco
Success Network, on page 136 for more information.

Move or Remove Smart Licenses from Managed Devices

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Global only Admin

Defense

Use this procedure to move a license from one Firepower Threat Defense device to another device registered
to the same Firepower Management Center, 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
Smart Licenses to a Different Firepower Management Center, on page 117.

Procedure

Step 1 Choose System > Licenses > Smart Licenses.

Step 2 Click Edit Licenses.
Step 3 Click either the Malware, Threat, URL Filtering, AnyConnect Plus, AnyConnect Apex, or AnyConnect
VPN Only tab.
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 icon ( ).
Step 5 Click Apply.

Transfer Smart 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 may receive an
Out-of-Compliance notification because your virtual account does not have enough free licenses.
See Deregister a Firepower Management Center from the Cisco Smart Software Manager, on page 118, then
search for "Transferring a license" in the Cisco Smart Software Management Center online help.

If Smart License Status is Out of Compliance

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Global only Admin

Defense

Firepower Management Center Configuration Guide, Version 6.3

117
 Firepower System Management
Deregister a Firepower Management Center from the Cisco Smart Software Manager

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

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 Smart Licensing, on page 119.

Step 4 In Firepower Management Center, select System > Licenses > Smart Licenses.
Step 5 Click the Re-Authorize button.

Deregister a Firepower Management Center from the Cisco Smart Software

Manager
Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Global only Admin

Defense

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 114 or Assign Licenses to Managed Devices from the Device
Management Page, on page 129.

Procedure

Step 1 Choose System > Licenses > Smart Licenses.

Step 2 Click the deregister icon ( ).

Firepower Management Center Configuration Guide, Version 6.3

118
 Firepower System Management
Synchronize a Firepower Management Center with the Cisco Smart Software Manager

Synchronize a Firepower Management Center with the Cisco Smart Software

Manager
Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Global only Admin

Defense

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

Step 1 Choose System > Licenses > Smart Licenses.

Step 2 Click the refresh icon ( ).

Troubleshoot Smart 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.

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 118.
• Try synchronizing: Synchronize a Firepower Management Center with the Cisco Smart Software Manager,
on page 119.

Licensing for All Other Firepower Devices (Classic Licensing)

7000 and 8000 Series devices, 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.

Firepower Management Center Configuration Guide, Version 6.3

119
 Firepower System Management
Product License Registration Portal

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:
http://www.cisco.com/web/go/license
For more information on using this portal, see:
https://www.cisco.com/web/fw/tools/swift/xui/html/help.html

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 5: 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

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 7000 and 8000 Series devices, NGIPSv devices, and ASA FirePOWER
modules. You cannot enable a license on a managed device unless the license exactly matches the device’s
model. For example, you cannot use a Firepower 8250 Malware license (FP8250-TAM-LIC=) to enable

Firepower Management Center Configuration Guide, Version 6.3

120
 Firepower System Management
Classic License Types and Restrictions

Malware capabilities on an 8140 device; you must purchase a Firepower 8140 Malware license
(FP8140-TAM-LIC=).

Note For NGIPSv or ASA FirePOWER, the Control license allows you to perform user and application control,
but these devices do not support switching, routing, stacking, or 7000 and 8000 Series device high availability.

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 6: 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 7000 and 8000 Series host, application, and user none depends on
TAMC discovery license
ASA FirePOWER
decrypting and inspecting
NGIPSv
SSL- and TLS-encrypted
traffic

Protection TA (included with 7000 and 8000 Series intrusion detection and none no
device) prevention
ASA FirePOWER
file control
NGIPSv
Security Intelligence
filtering

Control none (included with 7000 and 8000 Series user and application control Protection no
device)
switching and routing
7000 and 8000 Series device
high availability
7000 and 8000 Series
network address translation
(NAT)

Control none (included with ASA FirePOWER user and application control Protection no
device)
NGIPSv

Malware TAM, TAMC, or 7000 and 8000 Series AMP for Networks Protection yes
AMP (network-based Advanced
ASA FirePOWER
Malware Protection)
NGIPSv

Firepower Management Center Configuration Guide, Version 6.3

121
 Firepower System Management
Protection Licenses

License You Assign Service Subscription Platforms Granted Capabilities Also Expire
in Firepower System You Purchase Requires Capable?

URL Filtering TAC, TAMC, or 7000 and 8000 Series category and Protection yes
URL reputation-based URL
ASA FirePOWER
filtering
NGIPSv

VPN none (contact Sales 7000 and 8000 Series deploying virtual private Control yes
for more networks
information)

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 blacklist—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 blacklist connections based on the latest intelligence. Optionally, you
can use a “monitor-only” setting for Security Intelligence filtering.

A Protection license (along with a Control license) is automatically included in the purchase of any Classic
managed device. This license is perpetual, but you must also purchase a TA subscription to enable system
updates.
Although you can configure an access control policy to perform Protection-related inspection without a license,
you cannot deploy the policy until you first add a Protection license to the Firepower Management Center,
then enable it on the devices targeted by the policy.
If you delete your Protection license from the Firepower Management Center or disable Protection on managed
devices, the Firepower Management Center stops acknowledging intrusion and file events from the affected
devices. As a consequence, correlation rules that use those events as a trigger criteria stop firing. Additionally,
the Firepower Management Center will not contact the internet for either Cisco-provided or third-party Security
Intelligence information. You cannot re-deploy existing policies until you re-enable Protection.
Because a Protection license is required for URL Filtering, Malware, and Control licenses, deleting or disabling
a Protection license has the same effect as deleting or disabling your URL Filtering, Malware, or Control
license.

Control Licenses
A Control license allows you to implement user and application control by adding user and application
conditions to access control rules. For 7000 and 8000 Series devices only, this license also allows you to
configure switching and routing (including DHCP relay and NAT) and device high-availability pairs. To

Firepower Management Center Configuration Guide, Version 6.3

122
 Firepower System Management
URL Filtering Licenses for Classic Devices

enable a Control license on a managed device, you must also enable a Protection license. A Control license
is automatically included (along with a Protection license) in the purchase of any Classic managed device.
This license is perpetual, but you must also purchase a TA subscription to enable system updates.
If you do not enable a Control license for a Classic managed device, you can add user and application conditions
to rules in an access control policy, but you cannot deploy the policy to the device. If you do not enable a
Control license for 7000 or 8000 Series devices specifically, you also cannot:
• create switched, routed, or hybrid interfaces
• create NAT entries
• configure DHCP relay for virtual routers
• deploy a device configuration that includes switch or routing to the device
• establish high availability between devices

Note Although you can create virtual switches and routers without a Control license, they are not useful without
switched and routed interfaces to populate them.

If you delete a Control license from the Firepower Management Center or disable Control on individual
devices, the affected devices do not stop performing switching or routing, nor do device high-availability
pairs break. You can continue to edit and delete existing configurations, but you cannot deploy those changes
to the affected devices. You cannot add new switched, routed, or hybrid interfaces, nor can you add new NAT
entries, configure DHCP relay, or establish 7000 or 8000 Series device high-availability. Finally, 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,
then enable it on the devices targeted by the policy.
You may lose access to URL filtering if you delete the license from the Firepower Management Center or
disable URL Filtering on managed devices. Also, URL Filtering licenses may expire. If your license expires
or if you delete or disable it, access control rules with URL conditions immediately stop filtering URLs, and
your Firepower Management Center can no longer download updates to URL data. You cannot re-deploy
existing access control policies if they include rules with category and reputation-based URL conditions.

Firepower Management Center Configuration Guide, Version 6.3

123
 Firepower System Management
Malware Licenses for Classic Devices

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.

Note 7000 and 8000 Series managed devices with Malware licenses enabled attempt to connect periodically 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.
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.

Related Topics
When Events Appear in the Event Viewer, on page 2451

VPN Licenses
VPN allows you to establish secure tunnels between endpoints via a public source, such as the Internet or
other network. You can configure the Firepower System to build secure VPN tunnels between the virtual
routers of 7000 and 8000 Series devices. To enable VPN, you must also enable Protection and Control licenses.
To purchase a VPN license, contact Sales.
Without a VPN license, you cannot configure a VPN deployment with your 7000 and 8000 Series devices.
Although you can create deployments, they are not useful without at least one VPN-enabled routed interface
to populate them.
If you delete your VPN license from the Firepower Management Center or disable VPN on individual devices,
the affected devices do not break the current VPN deployments. Although you can edit and delete existing
deployments, you cannot deploy your changes to the affected devices.

Firepower Management Center Configuration Guide, Version 6.3

124
 Firepower System Management
Classic Licenses in Device Stacks and High-Availability Pairs

Classic Licenses in Device Stacks and High-Availability Pairs

Individual devices must have equivalent licenses before they can be stacked or configured into 7000 or 8000
Series device high-availability pairs. After you stack devices, you can change the licenses for the entire stack.
However, you cannot change the enabled licenses on a 7000 or 8000 Series device high-availability pair.
See also About Device Stacks, on page 565 and Device High Availability Requirements, on page 550.

View Your Classic Licenses

Smart License Classic License Supported Devices Supported Domains Access

N/A Any Classic Global only Admin

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 239, including Health Modules, on page 240
and Creating Health Policies, on page 248.

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 228 and Adding Widgets
to a Dashboard, on page 232 and Dashboard Widget
Availability by User Role, on page 219.

Identify the License Key

Smart License Classic License Supported Devices Supported Domains Access

N/A Any Classic Global only Admin

Firepower Management Center Configuration Guide, Version 6.3

125
 Firepower System Management
Generate a Classic License and Add It to the Firepower Management Center

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 126.
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

Smart License Classic License Supported Devices Supported Domains Access

N/A Any Classic Global only Admin

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
125.

Firepower Management Center Configuration Guide, Version 6.3

126
 Firepower System Management
How to Convert a Classic License or PAK to a Smart License

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. For more information, see
https://www.cisco.com/web/fw/tools/swift/xui/html/help.html.
This step requires the PAK you received during the purchase process, as well as the license key for the
Firepower Management Center.

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 129. You must assign licenses to your managed devices before you can use
licensed features on those devices.

How to Convert a Classic License or PAK to a Smart License

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.

Firepower Management Center Configuration Guide, Version 6.3

127
 Firepower System Management
How to Convert a Classic License or PAK to a Smart License

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 93.
• 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:

Firepower Management Center Configuration Guide, Version 6.3

128
 Firepower System Management
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 114.
b) Verify that the new Smart License has been successfully applied to the device.
See View Your Smart Licenses and Smart Licenses Status, on page 115.

Step 6 If you have not yet deployed Smart Licensing on your Firepower Management Center:
See How to License Firepower Threat Defense Devices Managed by Firepower Management Center , on page
81. (Skip any steps that do not apply or that you have already completed.)

Assign Licenses to Managed Devices from the Device

Management Page
Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Leaf only Admin/Network

Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

129
 Firepower System Management
Assign Licenses to Managed Devices from the Device Management Page

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

• Add your devices to the Firepower Management Center. See Add Devices to the Firepower Management
Center, on page 499.
• 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
114
• Prepare Smart Licenses for distribution to managed devices: See Register Smart Licenses, on page
95

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to assign or disable a license, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Device tab.

Step 4 Next to the License section, click the edit icon ( ).

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.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

130
 Firepower System Management
Firepower License and Service Subscription Expiration

Firepower License and Service Subscription Expiration

• License Expiration vs. Service Subscription Expiration
• Smart Licensing
• 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.

Firepower Management Center Configuration Guide, Version 6.3

131
 Firepower System Management
Firepower License and Service Subscription 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. To determine the status of your service subscriptions, see How can I tell if my
Classic licenses/service subscriptions are expired or about to expire?, on page ?.
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:

Firepower Management Center Configuration Guide, Version 6.3

132
Firepower System Management
Firepower License and Service Subscription Expiration

Table 7: 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.

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.

Firepower Management Center Configuration Guide, Version 6.3

133
 Firepower System Management
Other Licensing Information in This Guide

Classic License Possible Supporting Expiration Impact

Subscriptions

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.

Other Licensing Information in This Guide

For See

Information about the interface for FMC About Management Interfaces, on page 1006 and
communications with the Smart Licensing authority subtopics

Firewall requirements for licensing Internet Access Requirements, on page 2679

An explanation of the licensing information in tables License Statements in the Documentation, on page
at the beginning of each procedure in this document. 14

Important licensing considerations when restoring Restoring a Firepower Management Center, 7000 or
from a backup 8000 Series Device from a Backup File, on page 173

Firepower Management Center Configuration Guide, Version 6.3

134
 Firepower System Management
Additional Information about Firepower Licensing

For See

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 1370
• Access Control Rule Components, on page 1371,
information about Conditions
• TLS/SSL Rule Guidelines and Limitations, on
page 1483
• TLS/SSL Rule Components
• Rate Limiting with QoS Policies, on page 694

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 351
• Rate Limiting with QoS Policies, on page 694

Licensing requirements for SSL Prerequisites in Configure SSL Settings , on page 1102
for Firepower Threat Defense

Licensing requirements for SSL preprocessor The SSL Preprocessor, on page 1931
functionality

Licensing for AMP for Endpoints integrations Comparison of Malware Protection: Firepower vs.
AMP for Endpoints, on page 1578

Licensing and stream reassembly on client and server TCP Stream Preprocessing Options, on page 1970
services

Licensing and Cisco Threat Intelligence Director Platform, Element, and License Requirements, on
(TID) page 1592

Licensing impacts on connection events Requirements for Populating Connection Event Fields,
on page 2478

Information about the Licensing and other dashboard Dashboard Widget Availability by User Role, on page
widgets 219
The Custom Analysis Widget, on page 222

Information about the Health Monitor for licensing. Information about the Smart License Monitor and the
Classic License Monitor in Health Modules, on page
240

Additional Information about Firepower Licensing

For additional information to help resolve common licensing questions, see the following documents:

Firepower Management Center Configuration Guide, Version 6.3

135
 Firepower System Management
Cisco Success Network

• The Frequently Asked Questions (FAQ) about Firepower Licensing document at:
https://www.cisco.com/c/en/us/td/docs/security/firepower/licensing/faq/firepower-licence-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.
• To help Cisco improve our products.

The Firepower Management Center establishes and maintains the secure connection at all times, and allows
you to enroll in the Cisco Success Network. You can turn off this connection at any time by disabling Cisco
Success Network, which disconnects the device from the Cisco Success Network cloud.

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 95.
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 141.

Note The Cisco Success Network feature is disabled if the Firepower Management Center has a valid Smart Software
Satellite Server configuration, or uses Specific License Reservation.

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 137.

Firepower Management Center Configuration Guide, Version 6.3

136
 Firepower System Management
Enrolled Device Data

• 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 138.
• 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 138.
• 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 139.
• 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 8: Enrolled Device Telemetry Data

Data Point Example Value

Device Name Management Center East

Device UUID 24fd0ccf-1464- 491f-a503- d241317bb327

HA Peer UUID 24fe0ccd-1564- 491h-b802- d321317cc827

Device Model Cisco Firepower Management Center 4000

Cisco Firepower Management Center for VMWare

Serial Number 9AMDESQP6UN

System Uptime 99700000

Product Identifier FMC4000-K9

FS-VMW-SW-K9

Smart License PIID 24fd0ccf-1464- 491f-a503- d241317bb327

Virtual Account Identifier CiscoSVStemp

Firepower Management Center Configuration Guide, Version 6.3

137
 Firepower System Management
Software Version Data

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 9: Software Version Telemetry Data

Data Point Example Value

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 10: Managed Device Telemetry Data

Data Point Example Value

Managed Device Name firepower

Managed Device Version 6.2.3-10616

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

Is Threat License Used for Device? True

Does AC Policy Have Intrusion Rule Attached? True

Firepower Management Center Configuration Guide, Version 6.3

138
 Firepower System Management
Deployment Information

Data Point Example Value

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 Need 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 11: Deployment Information

Data Point Example Value

Job ID 8589936079

Number of Devices Selected for Deployment 3

Number of Devices with Deployment Failure 1

Number of Devices with Deployment Success 2

End Time 1523993913001

Start Time 1523993840445

Status SUCCEEDED

UUID of the Target Device 4f14f644-41e0 -11e8-9354- cf32315d7095

Policy Types Deployed NetworkDiscovery

NGFWPolicy
DeviceConfiguration

Last Deployment Job ID Collected in Current Run 8589936079

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:

{
"version": "1.0",
"metadata": {

Firepower Management Center Configuration Guide, Version 6.3

139
 Firepower System Management
Telemetry Example File

"topic": "fmc.telemetry",
"contentType": "application/json"
},
"payload": {
"recordType": "CST_FMC",
"recordVersion": "6.3.0",
"recordedAt": 1509133291334,
"fmc": {
"deviceInfo": {
"deviceModel": "Cisco Firepower Management Center",
"deviceName": "FMC",
"deviceUuid": "c40d793c-bb33-11e7-804d-6f32258941f8",
"serialNumber": "615-10110800010110",
"smartLicenseProductInstanceIdentifier": "0fa56138-5211-442a-846c-97b6431146fd",
"smartLicenseVirtualAccountName": "Firepower Threat Defense",
"systemUptime": 11658000,
"udiProductIdentifier": "FMC4500-K9T"
},
"versions": {
"items": [{
"type": "SOFTWARE",
"version": "6.3.0-10222"
}, {
"lastUpdated": 0,
"type": "SNORT_RULES_DB",
"version": "2018-02-13-001-vrt"
}, {
"lastUpdated": 0,
"type": "VULNERABILITY_DB",
"version": "290"
}, {
"type": "GEOLOCATION_DB",
"version": "None"
}]
}
},
"managedDevices": {
"items": [{
"deviceInfo": {
"deviceManager": "FMC",
"deviceModel": "Cisco Firepower 2130 NGFW Appliance",
"deviceName": "10.2.4.107",
"deviceVersion": "6.3.0-10222",
"serialNumber": "515-10110800100010"
},
"urlFiltering" : {
"urlFilteringLicenseUsed" : True,
"acRulesWithURLFiltering" : 10
}
},
{
"deviceInfo": {
"deviceManager": "FMC",
"deviceModel": "Cisco Firepower 2140 NGFW Appliance",
"deviceName": "192.168.0.119",
"deviceVersion": "6.3.0-10222",
"serialNumber": "725-10010900101020"
},
"urlFiltering" : {
"urlFilteringLicenseUsed" : True,
"acRulesWithURLFiltering" : 10
}
}, {
"deviceInfo": {

Firepower Management Center Configuration Guide, Version 6.3

140
 Firepower System Management
Changing Cisco Success Network Enrollment

"deviceManager": "FMC",
"deviceModel": "Cisco Firepower Threat Defense for VMWare",
"deviceName": "192.168.0.117",
"deviceVersion": "6.3.0-10222",
"serialNumber": "None"
},
"urlFiltering" : {
"urlFilteringLicenseUsed" : False,
"acRulesWithURLFiltering" : 0
}
}]
},
"deploymentData": {
"deployJobInfoList": [{
"jobDeviceList": [{
"deployEndTime": "1523959960957",
"deployStartTime": "1523959863411",
"deployStatus": "SUCCEEDED",
"deviceUuid": "4f14f644-41e0-11e8-9354-cf32315d7095",
"pgTypes": "[PG.FIREWALL.NGFWAccessControlPolicy, PG.FIREWALL.PrefilterPolicy,
PG.PLATFORM.NgfwInlineSetPage]"
}],
"jobId": "8589935776",
"numberOfDevices": 1,
"numberOfFailedDevices": 0,
"numberOfSuccessDevices": 1
},{
"jobDeviceList": [{
"deployEndTime": "1523993913001",
"deployStartTime": "1523993840445",
"deployStatus": "SUCCEEDED",
"deviceUuid": "4f14f644-41e0-11e8-9354-cf32315d7095",
"pgTypes": "[PG.FIREWALL.NGFWAccessControlPolicy, PG.FIREWALL.PrefilterPolicy,
PG.PLATFORM.NgfwInlineSetPage]"
}],
"jobId": "8589936079",
"numberOfDevices": 1,
"numberOfFailedDevices": 0,
"numberOfSuccessDevices": 1
}],
"lastJobId": "8589936079"
}
}
}

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, then click Licenses > Smart Licenses.

Firepower Management Center Configuration Guide, Version 6.3

141
 Firepower System Management
End-User License Agreement

Step 2 Under Smart License Status, next to Cisco Success Network, click the 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 1062.

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

Feature Version Details

Licensing for multi-instance capability for 6.3 You can now deploy multiple FTD
the FTD on the Firepower 4100/9300 container instances on a Firepower
4100/9300. You only need a single license
per feature per security module/engine. The
base license is automically assigned to each
instance.
New/Modified screens:
System > Licenses > Smart Licenses
Supported platforms: FTD on the Firepower
4100/9300

Specific License Reservation for air-gapped 6.3 Customers whose deployments cannot
deployments connect to the internet to communicate with
the Cisco License Authority can use a
Specific License Reservation.
New/Modified screens:
System > Licenses > Specific Licenses
(This option is not available by default.)
Supported platforms: Firepower
Management Center and Firepower Threat
Defense
For details, see: Specific License
Reservation Overview, on page 101.

Firepower Management Center Configuration Guide, Version 6.3

142
 Firepower System Management
History for Licensing

Feature Version Details

Export-controlled functionality for 6.3 Certain customers whose Smart Accounts

restricted customers are not otherwise eligible to use restricted
functionality can purchase term-based
licenses, with approval.
Supported platforms: Firepower
Management Center and Firepower Threat
Defense
For details, see: Enabling the Export
Control Feature (for Accounts Without
Global Permission), on page 96.

Enhanced instructions for deploying Smart 6.3 • A new topic provides end-to-end
Licensing for Firepower Threat Defense guidance: How to License Firepower
devices Threat Defense Devices Managed by
Firepower Management Center , on
page 81
• New and improved information in
topics linked from this topic.

Firepower Management Center Configuration Guide, Version 6.3

143
 Firepower System Management
History for Licensing

Firepower Management Center Configuration Guide, Version 6.3

144
 CHAPTER 6
System Software Updates
The following topics explain how to update Firepower deployments:
• About Firepower Updates, on page 145
• Guidelines and Limitations for Firepower Updates, on page 146
• Upgrade Firepower System Software, on page 146
• Update the Vulnerability Database (VDB) Manually, on page 147
• Update the Geolocation Database (GeoDB), on page 148
• Update Intrusion Rules, on page 150
• Maintain Your Air-Gapped Deployment, on page 160

About Firepower Updates

Cisco distributes several types of upgrades and updates for Firepower deployments. Unless otherwise
documented in the release notes or advisory text, updating does not modify configurations. Note that you
cannot uninstall major upgrades, nor can you return to previous versions of the VDB, GeoDB, or SRU.

Table 12: Firepower Upgrades and Updates

Update Type Description Domain

Major upgrade Includes new features and functionality, and may entail large-scale Global only
changes to the product.
Can be freshly installed or restored, but not uninstalled.
For devices where you upgrade the operating system separately, likely
to have a companion operating system upgrade.
May require you to re-accept the Cisco End User License Agreement
(EULA)

Minor upgrade Contains a limited range of fixes. Global only

(patch)
Can be uninstalled, but not freshly installed or restored. You must restore
to a major version, then upgrade to the minor version.

Vulnerability Updates detection of vulnerabilities, operating systems, applications, Global only

Database (VDB) clients, and file types eligible for dynamic analysis.

Firepower Management Center Configuration Guide, Version 6.3

145
 Firepower System Management
Guidelines and Limitations for Firepower Updates

Update Type Description Domain

Intrusion rules Provides new and updated intrusion rules and preprocessor rules, Cisco-provided:
(SRUs) modified states for existing rules, and modified default intrusion policy Global only
settings.
Local imports:
May also delete rules, provide new rule categories and default variables, Any
and modify default variable values.

Geolocation Updates information on physical locations, connection types, and so on, Global only
database that can be associated with detected routable IP addresses. You must
(GeoDB) install the GeoDB to view geolocation details or perform
geolocation-based access control.

Guidelines and Limitations for Firepower Updates

Before You Update
Before you update any component of your Firepower deployment (including the VDB, GeoDB, or SRU) you
must 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.
For details on how to prepare for and complete a successful system software upgrade of a Firepower
Management Center deployment, see the Firepower Management Center Upgrade Guide.

Bandwidth Guidelines
Updates can require large data transfers from the Firepower Management Center to managed devices. Before
you begin, make sure your management network has sufficient bandwidth to successfully perform the transfer.
See the Troubleshooting Tech Note at https://www.cisco.com/c/en/us/support/docs/security/
firepower-management-center/212043-Guidelines-for-Downloading-Data-from-the.html.

Upgrade Firepower System Software

Upgrading a Firepower Management Center deployment can be complex process. Careful planning and
preparation can help you avoid missteps. You should consider planning and preparation as much a part of the
upgrade process as actually performing the mechanical steps that invoke the upgrade scripts.
The first step in the process is to assess your deployment and create an upgrade path—a detailed plan for
which appliances you will upgrade, what components you will upgrade, and in what order. Your upgrade path
should:
• Maintain manager-device compatibility.
• Include operating system and hosting environment upgrades where necessary.
• Include other tasks such as backups, package downloads and pushes, readiness checks, bandwidth and
disk space checks, pre- and post-upgrade configuration changes, and so on.
• Identify potential interruptions in traffic flow and inspection.

Firepower Management Center Configuration Guide, Version 6.3

146
 Firepower System Management
Update the Vulnerability Database (VDB) Manually

For details on how to prepare for and complete a successful upgrade of a Firepower Management Center
deployment, see Firepower Management Center Upgrade Guide.

Update the Vulnerability Database (VDB) Manually

Smart License Classic License Supported Devices Supported Domains Access
Any Any Any Global only Admin

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.
The Cisco Talos Security Intelligence and Research Group (Talos) 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.
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 206.

Important If you do not schedule automatic VDB updates, you should regularly check for these updates. Updates occur
no more than once daily and are posted to the appropriate child pages of https://www.cisco.com/go/
firepower-software.

Caution If a warning appears when you select the Firepower Management Center to begin installing a vulnerability
database (VDB) update, you must deploy configurations after installing the VDB, and the deploy restarts the
Snort process. Additional warnings appear on the deploy dialog for pending deploys to Firepower Threat
Defense devices. Whether traffic drops or passes without further inspection during the deploy interruption
depends on how the targeted device handles traffic. See Snort® Restart Traffic Behavior, on page 312 for more
information. VDB updates that apply only to the Firepower Management Center do not cause restarts, and
you cannot deploy them.

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 the Product Updates tab.
Step 2 Choose how you want to upload the VDB update to the Firepower Management Center.

Firepower Management Center Configuration Guide, Version 6.3

147
 Firepower System Management
Update the Geolocation Database (GeoDB)

• 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 the Install icon 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
Deploy configuration changes; see Deploy Configuration Changes, on page 308.
Deploy configurations

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. You must install the GeoDB on your
system to view any geolocation details other than country or continent. Cisco issues periodic updates to the
GeoDB.
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.

Firepower Management Center Configuration Guide, Version 6.3

148
 Firepower System Management
Manually Update the GeoDB (Internet Connection)

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)

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Global only Admin

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 the Geolocation Updates tab.
Step 3 Choose Download and install geolocation update from the Support Site.
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 285.
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)

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Global only Admin

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
(http://www.cisco.com/cisco/web/support/index.html).

Firepower Management Center Configuration Guide, Version 6.3

149
 Firepower System Management
Schedule GeoDB Updates

Step 2 Choose System > Updates.

Step 3 Click the Geolocation Updates tab.
Step 4 Choose Upload and install geolocation update.
Step 5 Browse to the update you downloaded, and click Upload.
Step 6 Click Import.
Step 7 Optionally, monitor the task status; see Viewing Task Messages, on page 285.
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

Smart License Classic License Supported Devices Supported Domains Access
Any Any Any Global only Admin

If the Firepower Management Center has internet access, we recommend you schedule weekly GeoDB updates.

Before you begin

Make sure the Firepower Management Center can access the internet.

Procedure

Step 1 Choose System > Updates, then click the Geolocation Updates tab.
Step 2 Under Recurring Geolocation Updates, check Enable Recurring Weekly Updates.
Step 3 Specify the Update Start Time.
Step 4 Click Save.

Update Intrusion Rules

As new vulnerabilities become known, the Cisco Talos Security Intelligence and Research 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.

Firepower Management Center Configuration Guide, Version 6.3

150
Firepower System Management
Update Intrusion Rules

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

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 icon ( ), 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.

Firepower Management Center Configuration Guide, Version 6.3

151
 Firepower System Management
Update Intrusion Rules One-Time Manually

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Global only Admin

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
(http://www.cisco.com/cisco/web/support/index.html).
Step 2 Choose System > Updates, then click the Rule Updates tab.
Step 3 If you want to move all user-defined rules that you have created or imported to the deleted folder, you must
click Delete All Local Rules in the toolbar, then click OK.
Step 4 Choose Rule Update or text rule file to upload and install and click Browse to navigate to and choose the
rule update file.
Step 5 If you want to automatically re-deploy policies to your managed devices after the update completes, choose
Reapply all policies after the rule update import completes.
Step 6 Click Import. The system installs the rule update and displays the Rule Update Log detailed view.
Note Contact Support if you receive an error message while installing the rule update.

Update Intrusion Rules One-Time Automatically

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Global only Admin

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 2679.

Firepower Management Center Configuration Guide, Version 6.3

152
 Firepower System Management
Configure Recurring Intrusion Rule Updates

Procedure

Step 1 Choose System > Updates.

Step 2 Click the Rule Updates tab.
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.
Step 6 Click Import.
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.

Configure Recurring Intrusion Rule Updates

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Global only Admin

Procedure

Step 1 Choose System > Updates.

Step 2 Click the Rule Updates tab.
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 the Enable Recurring Rule Update Imports 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.

Firepower Management Center Configuration Guide, Version 6.3

153
 Firepower System Management
Guidelines for Importing Local Intrusion Rules

The status message under the Recurring Rule Update Imports section heading changes to indicate that the
rule update has not yet run.

Guidelines 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.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

154
 Firepower System Management
Import Local Intrusion Rules

• 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 Guidelines for Importing Local Intrusion
Rules, on page 154.
• 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.

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin

Use this procedure to import local intrusion rules. Imported intrusion rules appear in the local rule category
in a disabled state.

Procedure

Step 1 Choose System > Updates, then click the Rule Updates tab.
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..., then click Choose
File and browse to your local rule file.
Step 4 Click Import.
Step 5 Monitor import progress in the Message Center.
To display the Message Center, click the System Status icon 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.

Firepower Management Center Configuration Guide, Version 6.3

155
 Firepower System Management
Rule Update Log

• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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 13: 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.

Status Whether the import:

• succeeded ( )

• failed or is currently in progress ( )

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin

Firepower Management Center Configuration Guide, Version 6.3

156
 Firepower System Management
Fields in an 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

Step 1 Choose System > Updates.

Tip You can also click Import Rules on the intrusion rules editor page (Objects > Intrusion Rules).

Step 2 Click the Rule Updates tab.

Step 3 Click Rule Update Log.
Step 4 You have two options:
• View details — To view details for each object imported in a rule update or local rule file, click view
icon ( ) next to the file you want to view; see Viewing Details of the Intrusion Rule Update Import
Log, on page 159.
• Delete — To delete an import file record from the import log, including detailed records for all objects
included with the file, click the delete icon ( ) 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.

Firepower Management Center Configuration Guide, Version 6.3

157
 Firepower System Management
Fields in an Intrusion Rule Update Log

Table 14: 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.

Firepower Management Center Configuration Guide, Version 6.3

158
 Firepower System Management
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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin

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

Step 1 Choose System > Updates.

Step 2 Click the Rule Updates tab.
Step 3 Click Rule Update Log.

Step 4 Click the view icon ( ) 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
2390 for more information.
• Switch workflows — To temporarily use a different workflow, click (switch workflows).

Firepower Management Center Configuration Guide, Version 6.3

159
 Firepower System Management
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:
• Update the Vulnerability Database (VDB) Manually, on page 147
• Update Intrusion Rules One-Time Manually, on page 152
• Manually Update the GeoDB (No Internet Connection), on page 149
• The Firepower Management Center Software Upgrade Guide at
https://www.cisco.com/c/en/us/td/docs/security/firepower/upgrade/fpmc-upgrade-guide.html

Firepower Management Center Configuration Guide, Version 6.3

160
 CHAPTER 7
Backup and Restore Introduction
The ability to recover from a disaster is an essential part of any system maintenance plan. As part of your
disaster recovery plan, Cisco recommends that you back up the Firepower Management Center and the managed
devices periodically. Backups are used to restore information while replacing a faulty or failed Firepower
Management Center appliance or 7000 or 8000 Series device or a Firepower Threat Defense device.The
following topics describe how to use the backup and restore features in the Firepower System:
• Backup and Restore Support, on page 161
• Backup and Restore Guidelines and Limitations, on page 162
• Backup Files, on page 165
• Backing Up a Firepower Management Center, on page 166
• Backing Up a 7000 or 8000 Series Device Locally, on page 168
• Backing Up Managed Devices from a Firepower Management Center, on page 169
• Creating Backup Profiles, on page 170
• Uploading Backups from a Local Host to a Firepower Management Center, 7000 or 8000 Series Device,
on page 171
• The Backup Management Page, on page 172
• Restoring a Firepower Management Center, 7000 or 8000 Series Device from a Backup File, on page
173
• Backup and Restore a Firepower Threat Defense Device, on page 175

Backup and Restore Support

You can back up and restore data from the following:
• Firepower Management Center
• 7000 and 8000 Series
• Firepower Threat Defense on Firepower 2100 series
• Firepower Threat Defense on Firepower 4100 series
• Firepower Threat Defense on Firepower 9300
• Firepower Threat Defense on ASA 5500-X series
• Firepower Threat Defense devices in a high availability configuration
• Firepower Threat Defense Virtual on VMware

Firepower Management Center Configuration Guide, Version 6.3

161
 Firepower System Management
Backup and Restore Guidelines and Limitations

Restriction Backup and restore is not supported for a Firepower Threat Defense Virtual device
running on KVM, AWS and Microsoft Azure.

Backup and Restore Guidelines and Limitations

You can save backup files to the Firepower Management Center, 7000 & 8000 Series device, Firepower
Threat Defense device, or to your local computer. If you are using a Firepower Management Center to perform
the backup, you can optionally use remote storage to optimize the available space. For more information, see
Remote Storage Management.

Note Backup and restore operations are not supported for NGIPSv, ASA FirePOWER modules and Firepower
Threat Defense Virtual running on KVM, AWS cloud or Microsoft Azure.

Note While the system collects backup data, there may be a temporary pause in data correlation, and the system
may prevent you from changing configurations related to the backup.

The following sections detail the backup and restore guidelines by device and functional area:
• Backup and Restore Guidelines and Limitations on Firepower Management Center and 7000, 8000 Series
Devices, on page 162
• Backup and Restore Guidelines and Limitations on Firepower Threat Defense Devices, on page 163
• Configuration Import/Export Guidelines for Firepower 4100/9300 , on page 164
• VPN Certificate Management on Firepower Threat Defense, on page 165

Related Topics
Remote Storage Management, on page 1024
About Configuration Import/Export, on page 187
Marking Intrusion Events Reviewed, on page 2502
Interface Objects: Interface Groups and Security Zones, on page 379

Backup and Restore Guidelines and Limitations on Firepower Management

Center and 7000, 8000 Series Devices
Note the following guidelines and limitations for backup and restore on the Firepower Management Center
and the 7000 & 8000 Series device:
• You can restore a backup onto a replacement appliance or device only if the two appliances or devices
are the same model and are running the same version of the Firepower System software.

Firepower Management Center Configuration Guide, Version 6.3

162
 Firepower System Management
Backup and Restore Guidelines and Limitations on Firepower Threat Defense Devices

• You can restore a backup onto a replacement appliance or device from the Firepower Management Center
web interface or the device's web interface respectively.
• On Firepower Management Centers, the backup and restore functions are available only in the Global
domain. You can use the export and import functions as substitutes for backup and restore within the
scope of a subdomain.
• Backups do not include captured file data.
• The backup files that contain certificates will be marked as failed once they are restored. Users must
therefore re-install certificates on the Firepower Management Center.
• When you restore a backup on a replacement appliance or device, any existing configuration on the
appliance or device will be deleted and completely replaced by the restored configuration.
• Cisco recommends that you backup your Firepower Management Center if you make any modifications
to Specific or Permanent License Reservation.
• Do not use the backup and restore process to copy configurations between appliances or devices. A
backup file contains information that uniquely identifies an appliance, and cannot be shared.
• After you restore a Firepower Management Center, you must apply the latest intrusion rule update.
• Private keys associated with PKI objects are encrypted with a randomly generated key when stored on
the appliance. If you perform a backup that contains private keys associated with PKI objects, the private
keys are decrypted before being included in the unencrypted backup file. Store the backup file in a secure
location.
• If you restore a backup that contains private keys associated with PKI objects, the system encrypts the
keys with a randomly generated key before storing them on the appliance.
• If you restore a backup that includes a file policy with either a clean list or custom detection list enabled,
the system merges any existing file lists(s) with the file lists(s) being restored.
• If you perform a backup, then delete reviewed intrusion events, then restore using that backup, the system
restores the deleted intrusion events but does not restore their reviewed status. You view those restored
intrusion events under Intrusion Events, not under Reviewed Events.
• If you restore a backup that contains intrusion event data on an appliance that already contains that data,
duplicate events are created. To avoid this, restore intrusion event backups only on appliances without
prior intrusion event data.

Backup and Restore Guidelines and Limitations on Firepower Threat Defense

Devices
Note the following guidelines and limitations for backup and restore on the Firepower Threat Defense:

Model Support
Backup and restore is not supported on:
• Firepower Threat Defense Virtual device running on KVM, AWS and Microsoft Azure
• Firepower Threat Defense devices in a cluster
• Firepower Threat Defense container instance

Firepower Management Center Configuration Guide, Version 6.3

163
 Firepower System Management
Configuration Import/Export Guidelines for Firepower 4100/9300

Additional Guidelines and Limitations

• You can restore a backup onto a replacement Firepower Threat Defense device only if the two devices
are the same model and are running the same version of the Firepower System software.
• You can create and restore backup files for Firepower Threat Defense devices in a high availability pair
from the Firepower Management Center. In a high availability deployment, the replacement Firepower
Threat Defense devices must have the same number of network modules and same type and number of
physical interfaces as the devices being replaced.
• You must use the Threat Defense CLI to restore a backup onto a replacement Firepower Threat Defense
device; you cannot perform a restore operation from a web interface.
• Backups do not include captured file data.
• If you unregister or unmanage the Firepower Threat Defense device from the Firepower Management
Center, the restore operation will only be partially complete.
When you re-register the Firepower Threat Defense device, the older security zone to interface mappings
in the Firepower Management Center will be lost and will have to be re-assigned to function as expected.
• For the Firepower 4100 series or Firepower 9300 devices, 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 before performing backup and restore operations. For
more information, follow the guidelines and restrictions listed in the "Configuration Import/Export"
section in the Cisco FXOS Firepower Chassis Manager Configuration Guide.
• When you restore a backup on a replacement Firepower Threat Defense device, any existing settings on
the device running configuration will be deleted and replaced by the restored configuration.
• For information about backup and restore of Cisco Threat Intelligence Director (TID) configurations and
data, see About Backing Up and Restoring TID Data, on page 1602.
• As part of restore operations, the Management IP of the replacement Firepower Threat Defense device
will be the same as the replaced Firepower Threat Defense device. To avoid IP conflicts, ensure that the
old Firepower Threat Defense device is not connected to the network.

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
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.

Firepower Management Center Configuration Guide, Version 6.3

164
 Firepower System Management
VPN Certificate Management on Firepower Threat Defense

• When you import a configuration to the Firepower 4100/9300 chassis, all existing configuration on the
Firepower 4100/9300 chassis (including any logical devices) will be deleted and completely replaced by
the configuration contained in the import file.
• We recommend that you only import a configuration file to the same Firepower 4100/9300 chassis from
which the configuration was exported.
• The platform software version of the Firepower 4100/9300 chassis to which 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 that you export a backup configuration whenever the Firepower 4100/9300
chassis is upgraded or downgraded.
• The Firepower 4100/9300 chassis to which 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 to which you are importing must have the correct software application
images installed for any logical devices defined in the export file that your are importing.
• To avoid overwriting existing backup files, please be sure to change the filename in the backup operation
or copy the existing file to another location.

VPN Certificate Management on Firepower Threat Defense

Note the following guidelines when performing backup and restore of a Firepower Threat Defense device
that uses VPN certificates:

Tip For instructions on enrolling or removing a VPN certificate on the Firepower Threat Defense device, see
Managing FTD Certificates, on page 464.

• When a new VPN certificate is added to the Firepower Management Center after the Firepower Threat
Defense device has been backed up, the Firepower Management Center will have the new certificate but
the Firepower Threat Defense device will not have it. You must re-enroll the new certificate on the
Firepower Threat Defense device. For more information, see Managing FTD Certificates, on page 464.
• During the restore operation, all the VPN configurations and certificates will be removed on the Firepower
Threat Defense device. After the restore operation, Firepower Management Center will show all the
certificate enrollments as failed. So you must re-enroll each certificate before deploying the configuration
from the Firepower Management Center.

Backup Files
The system backs up different data depending on the type of backup you perform. Note that the system does
not back up captured file data. Use the following table to determine what kind of backup you want to perform.

Warning The backup file must not be manually modified for the restore and upgrade process to function properly. You
must ensure there is no unauthorized access to the backup file.

Firepower Management Center Configuration Guide, Version 6.3

165
 Firepower System Management
Backing Up a Firepower Management Center

Table 15: Data Stored by Backup Type

Backup type Includes Includes event data? Includes unified Includes TID data?
configuration data? files?

Firepower Yes Yes No Yes

Management Center

7000 & 8000 Series, Yes No No No

performed from the
device itself

7000 & 8000 Series, Yes No Yes No

performed from the
managing Firepower
Management Center

Note You cannot create or restore backup files for NGIPSv devices, ASA FirePOWER modules and Firepower
Threat Defense Virtual on KVM, AWS cloud and Microsoft Azure. To back up event data, perform a backup
of the managing Firepower Management Center.

You should periodically save a backup file that contains all of the configuration files required to restore the
appliance, in addition to event data. You may also want to back up the system when testing configuration
changes so that you can revert to a saved configuration if needed. You can choose to save the backup file on
the appliance or on your local computer.
On Firepower Management Centers, the backup file can be saved to a remote location.
Related Topics
Remote Storage Management, on page 1024

Backing Up a Firepower Management Center

Smart License Classic License Supported Devices Supported Domains Access

Any Any Firepower Global only Admin/Maint

Management Center

You must perform this procedure using the Firepower Management Center web interface.

Before you begin

• Ensure your appliance has enough disk space; backups may fail if the backup process uses more than
90% of available disk space. If necessary, delete old backup files, transfer old backup files off the
appliance, or use remote storage; see Remote Storage Management, on page 1024.

Firepower Management Center Configuration Guide, Version 6.3

166
Firepower System Management
Backing Up a Firepower Management Center

Procedure

Step 1 Select System > Tools > Backup/Restore.

Step 2 Click Firepower Management Backup.
Step 3 Type a Name.
Step 4 You have two further options:
• To archive the configuration, select Back Up Configuration. In a multidomain deployment, you cannot
disable this option.
• To archive the entire event database, select Back Up Events.
• To archive TID configurations and the entire TID database, select Back Up Threat Intelligence Director.

Step 5 If you want to be notified when the backup is complete, select the Email check box and type your email
address in the accompanying text box.
Note To receive email notifications, you must configure a relay host as described in Configuring a Mail
Relay Host and Notification Address, on page 1041.

Step 6 To use secure copy (SCP) to copy the backup archive to a different machine, select the Copy when complete
check box, then type the following information in the accompanying text boxes:
• in the Host field, the hostname or IP address of the machine where you want to copy the backup
• in the Path field, the path to the directory where you want to copy the backup
• in the User field, the user name you want to use to log into the remote machine
• in the Password field, the password for that user name. If you prefer to access your remote machine with
an SSH public key instead of a password, you must copy the contents of the SSH Public Key field to
the specified user’s authorized_keys file on that machine.
Tip With this option cleared, the system stores temporary files used during the backup on the remote
server; temporary files are not stored on the remote server when this option is selected. Cisco
recommends that you periodically save backups to a remote location so the appliance can be
restored in case of system failure.

Step 7 You have the following options:

• To save the backup file to the appliance, click Start Backup. The backup file is saved in the
/var/sf/backup directory.

• To save this configuration as a backup profile that you can use later, click Save As New.

What to do next
• Store the backup file in a secure location if it contains PKI object data, as the private keys are stored
unencrypted within the backup.

Firepower Management Center Configuration Guide, Version 6.3

167
 Firepower System Management
Backing Up a 7000 or 8000 Series Device Locally

Backing Up a 7000 or 8000 Series Device Locally

Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 & 8000 Series N/A Admin/Maint

You must perform this procedure using the 7000 or 8000 Series device's local web interface.

Before you begin

• Ensure your appliance has enough disk space; backups may fail if the backup process uses more than
90% of available disk space. If necessary, delete old backup files, or transfer old backup files off the
appliance.

Procedure

Step 1 Select System > Tools > Backup/Restore.

Step 2 Click Device Backup.
Step 3 In the Name field, type a name for the backup file.
Step 4 If you want to be notified when the backup is complete, select the Email check box and type your email
address in the accompanying text box.
Note To receive email notifications, you must configure a relay host as described in Configuring a Mail
Relay Host and Notification Address, on page 1041.

Step 5 If you want to use secure copy (SCP) to copy the backup archive to a different machine, select the Copy when
complete check box, then type the following information in the accompanying text boxes:
• In the Host field, the hostname or IP address of the machine where you want to copy the backup.
• In the Path field, the path to the directory where you want to copy the backup.
• In the User field, the user name you want to use to log into the remote machine.
• In the Password field, the password for that user name. If you prefer to access your remote machine
with an SSH public key instead of a password, you must copy the contents of the SSH Public Key field
to the specified user’s authorized_keys file on that machine.
Tip With this option cleared, the system stores temporary files used during the backup on the remote
server; temporary files are not stored on the remote server when this option is selected. Cisco
recommends that you periodically save backups to a remote location so the appliance can be
restored in case of system failure.

Step 6 You have the following options:

• To save the backup file to the appliance, click Start Backup. The backup file is saved in the
/var/sf/backup directory.

Firepower Management Center Configuration Guide, Version 6.3

168
 Firepower System Management
Backing Up Managed Devices from a Firepower Management Center

• To save this configuration as a backup profile that you can use later, click Save As New.

What to do next
• Store the backup file in a secure location if it contains PKI object data, as the private keys are stored
unencrypted within the backup.

Backing Up Managed Devices from a Firepower Management

Center
Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except: Global only Admin/Maint

• NGIPSv
• Firepower
Threat Defense
Virtual on
KVM, AWS
cloud and
Microsoft
Azure
• ASA
FirePOWER
module

You must perform this procedure from the Firepower Management Center web interface.

Before you begin

• Ensure your appliance has enough disk space; backups may fail if the backup process uses more than
90% of available disk space. If necessary, delete old backup files, transfer old backup files off the
appliance, or use remote storage; see Remote Storage Management, on page 1024.

Procedure

Step 1 Select System > Tools > Backup/Restore.

Step 2 Click Managed Device Backup.
Step 3 In the Managed Devices field, select one or more managed devices.
Step 4 Uncheck the Retrieve to Management Center check box, to save each device’s backup file only on the
device. By default, the check box is checked and a copy of the backup file is saved to the Firepower
Management Center.

Firepower Management Center Configuration Guide, Version 6.3

169
 Firepower System Management
Creating Backup Profiles

Note If you select Retrieve to Management Center but your Firepower Management Center is configured
for remote storage of backups, the system will save the device backup file to the configured remote
location.

Step 5 Click Start Backup.

What to do next
Locate the backup file using the following information:
• The backup file is saved in the /var/sf/backup directory. If you choose to save a copy of the backup
file on the Firepower Management Center, it is saved in the /var/sf/remote-backup directory.
• The backup file follows the format <Displayname/IP>-<Timestamp>.tar for a standalone Firepower
Threat Defense device and the format <Displayname/IP>-<Role>-<Timestamp>.tar for a Firepower
Threat Defense device in a high availability pair.

Note If the backup contains PKI object data, store the backup in a secure location, as the private keys are stored
unencrypted within the backup.

Creating Backup Profiles

Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 & 8000 Series, Global only Admin/Maint

Firepower
Management Center

You must perform this procedure using the device's web user interface or the Firepower Management Center
web interface, as applicable.
You can create backup profiles that contain the settings that you want to use for different types of backups.
You can later select one of these profiles when you back up the files on your appliance.

Tip When you create a backup file for a Firepower Management Center using a new file name, the system
automatically creates a backup profile with that name.

Procedure

Step 1 Select System > Tools > Backup/Restore.

Step 2 Click the Backup Profiles tab.
Step 3 Click Create Profile.
Step 4 Type a name for the backup profile.

Firepower Management Center Configuration Guide, Version 6.3

170
 Firepower System Management
Uploading Backups from a Local Host to a Firepower Management Center, 7000 or 8000 Series Device

Step 5 Configure the backup profile. See Step 4 in Backing Up a Firepower Management Center, on page 166.
Step 6 Click Save As New to save the backup profile.

Uploading Backups from a Local Host to a Firepower

Management Center, 7000 or 8000 Series Device
Smart License Classic License Supported Devices Supported Domains Access

N/A Any Firepower Global only Admin/Maint

Management Center,
7000 & 8000 Series

You can upload a backup file from your local host to a Firepower Management Center, 7000 Series device
or a 8000 Series device using the Firepower Management Center web interface or the device's local web
interface respectively.
If your backup file contains PKI objects, on upload the system re-encrypts private keys associated with internal
CA and internal certificate objects with a randomly generated key.

Before you begin

• Download a backup file to your local host using the download function as described in The Backup
Management Page, on page 172.
• Copy backups larger than 4GB from your local host via SCP to a remote host and retrieve it from there
to your Firepower Management Center, as web browsers do not support uploading files that large. See
Remote Storage Management, on page 1024 for more information.

Procedure

Step 1 Select System > Tools > Backup/Restore.

Step 2 Click Upload Backup.
Step 3 Click Browse, then navigate to and select the backup file you want to upload.
Step 4 Click Upload Backup.
Step 5 Click Backup Management to return to the Backup Management page.

What to do next
• Refresh the Backup Management Page to view the detailed file system information after the appliance
verifies the file integrity.

Firepower Management Center Configuration Guide, Version 6.3

171
 Firepower System Management
The Backup Management Page

The Backup Management Page

You can access the Backup Management page on the Firepower Management Center web interface at
System > Tools > Backup/Restore > Backup Management. The Backup Management page displays
backup information for the Firepower Management Center, 7000 Series device, 8000 Series device and the
FTD device.
If your backup file contains PKI objects, on upload the system re-encrypts private keys associated with internal
CA and internal certificate objects with a randomly generated key.
If you use local storage, backup files are saved to /var/sf/backup, which is listed with the amount of disk
space used in the /var partition at the bottom of the Backup Management page. On Firepower Management
Centers, select Remote Storage at the top of the Backup Management page to configure remote storage
options; then, to enable remote storage, select the Enable Remote Storage for Backups check box on the
Backup Management page. If you use remote storage, the protocol, backup system, and backup directory are
listed at the bottom of the page.
The following table describes each column and button on the Backup Management page.

Table 16: Backup Management

Functionality Description

System Information The originating appliance name, type, and version

Note you can only restore a backup to an
identical appliance type and version.

Date Created The date and time that the backup file was created

File Name The full name of the backup file

VDB Version The build of the vulnerability database (VDB) running

on the appliance at the time of backup.

Location The location of the backup file

Size (MB) The size of the backup file, in megabytes

Events? “Yes” indicates the backup includes event data

View Click the name of the backup file to view a list of the
files included in the compressed backup file.

Restore Click with the backup file selected to restore it on the

appliance. If your VDB version does not match the
VDB version in the backup file, this option is disabled.
For more information, see Restoring a Firepower
Management Center, 7000 or 8000 Series Device from
a Backup File, on page 173

Download Click with the backup file selected to save it to your

local computer.

Firepower Management Center Configuration Guide, Version 6.3

172
 Firepower System Management
Restoring a Firepower Management Center, 7000 or 8000 Series Device from a Backup File

Functionality Description

Delete Click with the backup file selected to delete it.

Move On a Firepower Management Center, when you have

a previously created local backup selected, click to
send the backup to the designated remote backup
location.

Restoring a Firepower Management Center, 7000 or 8000 Series

Device from a Backup File
Smart License Classic License Supported Devices Supported Domains Access

N/A Any Firepower Global only Admin/Maint

Management Center,
7000 & 8000 Series

You can restore a Firepower Management Center, 7000 Series device or 8000 Series device from backup files
using the Backup Management page on the Firepower Management Center web interface or the device's
web interface.

Caution • This action overwrites all configuration files and, on the managed device, all event data.

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. If you de-register a Firepower Management Center from Cisco Smart Software Manager
after a backup has completed, and restore this backup, then you must de-register Firepower Management
Center and register the Firepower Management Center again.

Note For more information to de-register a Firepower Management Center, see Deregister a Firepower Management
Center from the Cisco Smart Software Manager, on page 118. To register the Firepower Management Center,
see Register Smart Licenses, on page 95.

Before you begin

• Confirm that the VDB version in the backup file matches the current VDB version on your appliance.
See Viewing Dashboards, on page 237 for more information.
• Remove any licenses added to your appliance after a backup has completed before restoring the backup
to avoid a conflict on restore. See About Firepower Licenses, on page 79 for more information.

Firepower Management Center Configuration Guide, Version 6.3

173
 Firepower System Management
Restoring a Firepower Management Center, 7000 or 8000 Series Device from a Backup File

• Confirm the appliance does not have the same intrusion event data as stored in the backup, because
restoring the backup under such conditions creates duplicate events. See About Intrusion Events, on page
2489 for more information.

Procedure

Step 1 Select System > Tools > Backup/Restore.

Step 2 Click on the backup file to view its contents. Details include file owner, file permissions, file size, and date.
Step 3 Select System > Tools > Backup/Restore to return to the Backup Management page.
Step 4 Select the backup file that you want to restore.
Step 5 Click Restore.
Note If the VDB version in the backup does not match the VDB version currently installed on your
appliance, the Restore button is grayed out.

Step 6 To restore files, select either or both of the following options:

• Restore Configuration Data
Note When you restore the configuration of a managed device from a backup file, any device
configuration changes you made from the device’s managing Firepower Management Center
will also be restored. Restoring a backup file will overwrite changes you made after you created
that backup file.

• Restore Event Data

• Restore Threat Intelligence Director Data

Step 7 Click Restore.

Step 8 (Optional) Wait for the system to reboot automatically.
The system reboots automatically only if the backup contains configuration data.

What to do next
• Import the latest Cisco Rule Update; see Update Intrusion Rules One-Time Manually, on page 152. If
you re-deploy policies as part of the import, you do not need to deploy configuration changes (below).
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.
• Add and reconfigure any licenses you removed from your appliance before restoring the backup.
• Contact Support if your appliance shows a license conflict on restore.

Firepower Management Center Configuration Guide, Version 6.3

174
 Firepower System Management
Backup and Restore a Firepower Threat Defense Device

Backup and Restore a Firepower Threat Defense Device

If you need to replace a failed or faulty Firepower Threat Defense device, follow one of the backup and restore
procedures listed below:
• Backup and Restore a Firepower 2100 Series Device, on page 175
• Backup and Restore a Firepower Threat Defense on a Firepower 4100 Series or Firepower 9300 device
, on page 176
• Backup and Restore a Firepower Threat Defense on ASA 5500-X Series Device, on page 180
• Backup and Restore Firepower Threat Defense Devices in a High Availability Configuration , on page
181
• Backup and Restore a Firepower Threat Defense Virtual Device, on page 185

Backup and Restore a Firepower 2100 Series Device

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower 2100 Global only Admin/Maint

series

To replace a faulty or failed Firepower 2100 series device, follow these steps.

Warning Do not unregister or unmanage the faulty Firepower Threat Defense device as it will stop all communication
with the Firepower Management Center.

Before you begin

• Review the Backup and Restore Guidelines and Limitations, on page 162.
• Make sure you have a backup of the Firepower 2100 series device deployed in your environment. For
more information see, Backing Up Managed Devices from a Firepower Management Center, on page
169.
The backup file is retained locally on the Firepower 2100 series device at /var/sf/backup. If you choose
to retain a backup on the Firepower Management Center, it is located in the /var/sf/remote-backup
directory.
• Contact the Cisco Technical Assistance Center (TAC) to request a replacement.

Procedure

Step 1 Unrack the faulty device from the network.

Firepower Management Center Configuration Guide, Version 6.3

175
 Firepower System Management
Backup and Restore a Firepower Threat Defense on a Firepower 4100 Series or Firepower 9300 device

Step 2 Deploy the replacement device on the network, connecting only the management interface and power on the
device. For more information, see the Cisco Firepower 2100 Series Using Firepower Management Center
Quick Start Guide.
Step 3 Ensure the replacement device is running the same version of the Firepower System software as the device
being replaced. If necessary, reimage the replacement device. For more information, see Cisco ASA and
Firepower Threat Defense Reimage Guide.
Step 4 Restore the backup on the Firepower 2100 series device using the restore command.
• To restore a backup from the local Firepower Threat Defense, use the restore remote-manager-backup
<backup tar-file> command.
• To restore a backup from an SCP-enabled remote network, use the restore remote-manager-backup
location <scp-hostname> <username> <filepath> <backup tar-file> command.

You can monitor the progress of the restore operation by viewing the logs at /var/log/restore.log on the
Firepower Threat Defense device.

What to do next
• When the restore is successful, the Firepower Threat Defense device connects to the Firepower
Management Center and becomes available. The policies on the restored Firepower Threat Defense
device will be out of date. Deploy configuration changes from the Firepower Management Center to
update the policies. For more information, see Deploy Configuration Changes, on page 308.

Note If the Firepower Threat Defense device uses VPN configurations, refer to the
VPN Certificate Management section in Backup and Restore Guidelines and
Limitations, on page 162.

• Connect the Firepower 2100 series device data interfaces to the network. For instructions, see the Cisco
Firepower Threat Defense for the Firepower 2100 Series Using Firepower Management Center Quick
Start Guide.

Backup and Restore a Firepower Threat Defense on a Firepower 4100 Series

or Firepower 9300 device
If you need to replace a failed or faulty Firepower Threat Defense device running on a Firepower 4100/9300
chassis you must refer to the following procedures:
1. Exporting an FXOS Configuration File, on page 176
2. Backup and Restore a Firepower Threat Defense on a Firepower 4100 Series or Firepower 9300 device,
on page 177

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.

Firepower Management Center Configuration Guide, Version 6.3

176
 Firepower System Management
Backup and Restore a Firepower Threat Defense on a Firepower 4100 Series or Firepower 9300 device

Please review the Configuration Import/Export Guidelines for Firepower 4100/9300 for important information
about using the configuration export feature.

Procedure

Step 1 Choose System > Configuration > Export.

Step 2 To export a configuration file to your local computer:
a) Click the Local radio button.
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 the Remote radio button.
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. If you omit the filename, the export procedure assigns a name to the file.
h) Click Export.
The configuration file is created and exported to the specified location.

Backup and Restore a Firepower Threat Defense on a Firepower 4100 Series or Firepower 9300
device
Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD on the Global only Admin/Maint

Firepower 4100
series and Firepower
9300

When a Firepower Threat Defense running on a Firepower 4100/9300 chassis encounters a hardware failure,
follow these steps to replace it.

Warning Do not unregister or unmanage the faulty Firepower Threat Defense device as it will stop all communication
with the Firepower Management Center.

Firepower Management Center Configuration Guide, Version 6.3

177
 Firepower System Management
Backup and Restore a Firepower Threat Defense on a Firepower 4100 Series or Firepower 9300 device

Before you begin

• Review the Backup and Restore Guidelines and Limitations, on page 162.
• Export FXOS configurations from the Firepower Chassis Manager. For more information, see Exporting
an FXOS Configuration File, on page 176.
• Make sure that you have a backup of the logical Firepower Threat Defense device running on a Firepower
4100/9300 chassis deployed in your environment. For more information see, Backing Up Managed
Devices from a Firepower Management Center, on page 169.
The backup file is retained locally on the Firepower 4100/9300 chassis at /var/sf/backup. If you choose
to retain a backup on the Firepower Management Center, it is located in the /var/sf/remote-backup
directory.
• When a Firepower Threat Defense device running on a Firepower 4100/9300 fails, contact the Cisco
Technical Assistance Center (TAC) to request a replacement.

Procedure

Step 1 Unrack the faulty Firepower 4100/9300 chassis from the network.
Step 2 Install the replacement Firepower 4100/9300 chassis on the network, connecting only the management interface
and power on the device. For more information, see the Cisco Firepower Threat Defense for Firepower 4100
Quick Start Guide or the Cisco Firepower Threat Defense for Firepower 9300 Quick Start Guide as applicable.
Step 3 Ensure that the Firepower Threat Defense is compatible with the FXOS version running on the replacement
device. If necessary, reimage the replacement device. For more information, see Cisco FXOS Firepower
Chassis Manager Configuration Guide.
Step 4 Import FXOS configuration settings that were previously exported from the Firepower Chassis Manager. For
more information, see Importing a Configuration File, on page 179.
Step 5 Restore the backup on the replacement Firepower Threat Defense device using the restore command.
• To restore a backup from the local Firepower Threat Defense, use the restore remote-manager-backup
<backup tar-file> command.
• To restore a backup from an SCP-enabled remote network, use the restore remote-manager-backup
location <scp-hostname> <username> <filepath> <backup tar-file> command.

You can monitor the progress of the restore operation by viewing the logs at /var/log/restore.log on the
Firepower Threat Defense.

What to do next
• When the restore is successful, the Firepower Threat Defense device connects to the Firepower
Management Center and becomes available. The policies on the restored Firepower Threat Defense
device will be out of date. Deploy configuration changes from the Firepower Management Center to
update the policies. For more information, see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

178
 Firepower System Management
Importing a Configuration File

Note If the logical Firepower Threat Defense device uses VPN configurations, refer
to the VPN Certificate Management section in Backup and Restore Guidelines
and Limitations, on page 162.

• Connect the Firepower 4100/9300 chassis device data interfaces to the network. For instructions, see
either the Cisco Firepower Threat Defense for Firepower 4100 Quick Start Guide or the Cisco Firepower
Threat Defense for Firepower 9300 Quick Start Guide .

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. Please review the Configuration Import/Export Guidelines for Firepower
4100/9300 for important information about using the configuration import feature.

Procedure

Step 1 Choose System > Configuration > Import.

Step 2 To import from a local configuration file:
a) Click the Local radio button.
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 the Remote radio button.
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 filename.
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.

Firepower Management Center Configuration Guide, Version 6.3

179
 Firepower System Management
Backup and Restore a Firepower Threat Defense on ASA 5500-X Series Device

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.

Backup and Restore a Firepower Threat Defense on ASA 5500-X Series Device
Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Global only Admin/Maint

Defense on ASA
5500-X Series

To replace a faulty or failed ASA 5500-X Series device, follow these steps.

Warning Do not unregister or unmanage the faulty Firepower Threat Defense device as it will stop all communication
with the Firepower Management Center.

Before you begin

• Review the Backup and Restore Guidelines and Limitations, on page 162.
• Make sure you have a backup of the ASA 5500-X series device deployed in your environment. For more
information see, Backing Up Managed Devices from a Firepower Management Center, on page 169.
The backup file is retained locally on the ASA 5500-X series device at /var/sf/backup. If you choose
to retain a backup on the Firepower Management Center, it is located in the /var/sf/remote-backup
directory.
• Contact the Cisco Technical Assistance Center (TAC) to request a replacement.

Procedure

Step 1 Unrack the faulty device from the network.

Step 2 Deploy the replacement device on the network, connecting only the management interface and power on the
device. For more information, see the appropriate Cisco Firepower Threat Defense for the ASA 5500-X Series
Using Firepower Management Center Quick Start Guide as applicable.
Step 3 Ensure the replacement device is running the same version of the Firepower System software as the device
being replaced. If necessary, reimage the replacement device. For more information, see Cisco ASA and
Firepower Threat Defense Reimage Guide.
Step 4 Restore the backup on the ASA 5500-X Series device using the restore command.
• To restore a backup from the local Firepower Threat Defense, use the restore remote-manager-backup
<backup tar-file> command.
• To restore a backup from an SCP-enabled remote network, use the restore remote-manager-backup
location <scp-hostname> <username> <filepath> <backup tar-file> command.

Firepower Management Center Configuration Guide, Version 6.3

180
 Firepower System Management
Backup and Restore Firepower Threat Defense Devices in a High Availability Configuration

You can monitor the progress of the restore operation by viewing the logs at /var/log/restore.log on the
Firepower Threat Defense device.

What to do next
• When the restore is successful, the Firepower Threat Defense device connects to the Firepower
Management Center and becomes available. The policies on the restored Firepower Threat Defense
device will be out of date. Deploy configuration changes from the Firepower Management Center to
update the policies. For more information, see Deploy Configuration Changes, on page 308.

Note If the Firepower Threat Defense device uses VPN configurations, refer to the
VPN Certificate Management section in Backup and Restore Guidelines and
Limitations, on page 162.

• Connect the ASA 5500-X Series device data interfaces to the network. For instructions, see the appropriate
Cisco Firepower Threat Defense for the ASA 5500-X Series Using Firepower Management Center Quick
Start Guide.

Backup and Restore Firepower Threat Defense Devices in a High Availability

Configuration
If you need to replace one or more failed or faulty Firepower Threat Defense devices in a high availability
pair, you must follow one of the procedures listed below.
• Backup and Restore a Firepower Threat Defense Device in a High Availability Pair , on page 182
• Backup and Restore Both Firepower Threat Defense Devices in a High Availability Pair , on page 183

Firepower Management Center Configuration Guide, Version 6.3

181
 Firepower System Management
Backup and Restore a Firepower Threat Defense Device in a High Availability Pair

Backup and Restore a Firepower Threat Defense Device in a High Availability Pair
Smart License Classic License Supported Devices Supported Domains Access

Any N/A Any except: Global only Admin/Maint

• NGIPSv
• Firepower
Threat Defense
Virtual on
KVM, AWS
cloud and
Microsoft
Azure
• ASA
FirePOWER
module
• Firepower
Management
Center
• 7000 and 8000
Series device

When a Firepower Threat Defense device in a high availability configuration encounters a hardware failure,
follow these steps to replace it.

Warning Do not unregister or unmanage the faulty Firepower Threat Defense device as it will stop all communication
with the Firepower Management Center.

Before you begin

• Review the Backup and Restore Guidelines and Limitations, on page 162.

Note If you are replacing a Firepower Threat Defense device running on a Firepower
4100/9300 chassis, export FXOS configurations from the Firepower Chassis
Manager before proceeding with Firepower Threat Defense backup and restore
operations. For more information, see the Configuration Import/Export chapter
in the Cisco FXOS Firepower Chassis Manager Configuration Guide.

• Make sure you have a backup for the Firepower Threat Defense high availability pair. For more
information, see Backing Up Managed Devices from a Firepower Management Center, on page 169.
The backup file is retained locally on the Firepower Threat Defense device at /var/sf/backup. If you
choose to retain a backup on the Firepower Management Center, it is located in the
/var/sf/remote-backup directory. The Firepower Management Center will create separate backup files

Firepower Management Center Configuration Guide, Version 6.3

182
 Firepower System Management
Backup and Restore Both Firepower Threat Defense Devices in a High Availability Pair

for the primary and secondary Firepower Threat Defense devices. For a Firepower Threat Defense device
in a high availability pair, the backup tar file follows the format <Hostname/IP>-<Role>-<Timestamp>.tar.
• When a Firepower Threat Defense device in a high availability pair fails, contact the Cisco Technical
Assistance Center (TAC) to request a replacement.

Procedure

Step 1 Unrack the faulty device from the network.

Step 2 Deploy the the replacement device on the network, connect the management interface and high availability
link and power on the device. For more information, see the appropriate Firepower Quick Start Guide.
Note To avoid traffic disruptions, make sure that none of the data interfaces are connected on the
replacement device.

Step 3 Ensure the replacement device is running the same version of the Firepower System software as the device
being replaced. If necessary, reimage the replacement device. For more information, see Cisco ASA and
Firepower Threat Defense Reimage Guide.
Step 4 Restore the backup on the Firepower Threat Defense device using the restore command on the command
line interface.
• To restore a backup from the local Firepower Threat Defense, use the restore remote-manager-backup
<backup tar-file> command.
• To restore a backup from an SCP-enabled remote network, use the restore remote-manager-backup
location <scp-hostname> <username> <filepath> <backup tar-file> command.

Select the appropriate backup file depending on whether the primary or secondary Firepower Threat Defense
device is being replaced. You can monitor the progress of the restore operation by viewing the logs at
/var/log/restore.log on the Firepower Threat Defense device.

When the restore completes successfully the device reboots.

What to do next
• Resume high-availability cofiguration between the high availability peers by using the configure
high-availability resume command on the command line interface.

• If the restore is successful the Firepower Threat Defense device connects to the Firepower Management
Center and becomes available. The policies on the restored Firepower Threat Defense device will be out
of date. Deploy configuration changes from the Firepower Management Center to update the policies.
For more information, see Deploy Configuration Changes, on page 308.
• Connect the Firepower Threat Defense device data interfaces to the network. For instructions see the
appropriate Cisco Firepower Threat Defense Using Firepower Management Center Quick Start Guide.

Backup and Restore Both Firepower Threat Defense Devices in a High Availability Pair
When both Firepower Threat Defense devices in a high availability configuration encounter a hardware failure,
follow these steps to replace them.

Firepower Management Center Configuration Guide, Version 6.3

183
 Firepower System Management
Backup and Restore Both Firepower Threat Defense Devices in a High Availability Pair

Warning Do not unregister or unmanage the faulty Firepower Threat Defense device as it will stop all communication
with the Firepower Management Center.

Before you begin

• Review the Backup and Restore Guidelines and Limitations, on page 162.

Note If you are replacing a Firepower Threat Defense device running on a Firepower
4100/9300 chassis, export FXOS configurations from the Firepower Chassis
Manager before proceeding with Firepower Threat Defense backup and restore
operations. For more information, see the Configuration Import/Export chapter
in the Cisco FXOS Firepower Chassis Manager Configuration Guide.

• Make sure you have a backup for the Firepower Threat Defense high availability pair. For more
information, see Backing Up Managed Devices from a Firepower Management Center, on page 169.
The backup file is retained locally on the Firepower Threat Defense device at /var/sf/backup. If you
choose to retain a backup on the Firepower Management Center, it is located in the
/var/sf/remote-backup directory. The Firepower Management Center will create separate backup files
for the primary and secondary Firepower Threat Defense devices. For a Firepower Threat Defense device
in a high availability pair, the backup tar file follows the format <Hostname/IP>-<Role>-<Timestamp>.tar.
• When the Firepower Threat Defense devices in a high availability pair fail, contact the Cisco Technical
Assistance Center (TAC) to request a replacement.

Procedure

Step 1 Unrack the faulty devices from the network.

Step 2 Deploy the the replacement devices on the network, connect the management interface and high availability
link and power on the device. For more information, see the appropriate Firepower Quick Start Guide.
Note To avoid traffic disruptions, make sure that none of the data interfaces are connected on the
replacement device.

Step 3 Ensure the replacement devices are running the same version of the Firepower System software as the devices
being replaced. If necessary, reimage the replacement devices. For more information, see Cisco ASA and
Firepower Threat Defense Reimage Guide.
Step 4 Restore the backup on both the Firepower Threat Defense devices sequentially using the restore command.
• To restore a backup from the local Firepower Threat Defense device, use the restore
remote-manager-backup <backup tar-file> command.
• To restore a backup from an SCP-enabled remote network, use the restore remote-manager-backup
location <scp-hostname> <username> <filepath> <backup tar-file> command.

Firepower Management Center Configuration Guide, Version 6.3

184
 Firepower System Management
Backup and Restore a Firepower Threat Defense Virtual Device

Select the corresponding backup file for the appropriate Firepower Threat Defense device being restored. You
can monitor the progress of the restore operation by viewing the logs at /var/log/restore.log on the
Firepower Threat Defense device.

When the restore completes successfuly the device reboots.

What to do next
• Resume high-availability cofiguration between the high availability peers by using the configure
high-availability resume command on the command line interface.

• If the restore is successful, the Firepower Threat Defense device connects to the Firepower Management
Center and becomes available. The policies on the restored Firepower Threat Defense device will be out
of date. Deploy configuration changes from the Firepower Management Center to update the policies.
For more information, see Deploy Configuration Changes, on page 308.
• Connect the Firepower Threat Defense device data interfaces to the network. For instructions see the
appropriate Cisco Firepower Threat Defense Using Firepower Management Center Quick Start Guide.

Backup and Restore a Firepower Threat Defense Virtual Device

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Global only Admin/Maint

Defense Virtual for
VMware

To replace a faulty or failed Firepower Threat Defense Virtual device running on VMware, follow these steps.

Note This procedure is not applicable to a Firepower Threat Defense Virtual device running on AWS, KVM or
Microsoft Azure.

Warning Do not unregister or unmanage the faulty Firepower Threat Defense device as it will stop all communication
with the Firepower Management Center.

Before you begin

• Review the Backup and Restore Guidelines and Limitations, on page 162.
• Make sure that you have a backup of the Firepower Threat Defense Virtual device deployed in your
environment. For more information see, Backing Up Managed Devices from a Firepower Management
Center, on page 169.
The backup file is retained locally on the Firepower Threat Defense Virtual device at /var/sf/backup.
If you choose to retain a backup on the Firepower Management Center, it is located in the
/var/sf/remote-backup directory.

Firepower Management Center Configuration Guide, Version 6.3

185
 Firepower System Management
Backup and Restore a Firepower Threat Defense Virtual Device

• Contact the Cisco Technical Assistance Center (TAC) to replace a corrupt Firepower Threat Defense
Virtual.

Procedure

Step 1 Deploy the Firepower Threat Defense Virtual using the VMware vSphere web client or vSphere Hypervisor.
For more information, see the Cisco Firepower Threat Defense Virtual for VMware Deployment Quick Start
Guide.
Step 2 Set up the Firepower Threat Defense Virtual device using the CLI. For more information, see the Cisco
Firepower Threat Defense Virtual for VMware Deployment Quick Start Guide.
Step 3 (Optional) Reimage the replacement device to ensure that it is running the same version of the Firepower
System software as the device being replaced. For more information, see the Cisco Firepower Threat Defense
Virtual for VMware Deployment Quick Start Guide.
Warning Copy the backup file from /var/sf/backup to a SCP-enabled remote location or the Firepower
Management Center before reimaging the Firepower Threat Defense Virtual device that you created
a backup of.

Step 4 Restore the backup on the Firepower Threat Defense Virtual using the restore command.
• To restore a backup from the local Firepower Threat Defense, use the restore remote-manager-backup
<backup tar-file> command.
• To restore a backup from an SCP-enabled remote network, use the restore remote-manager-backup
location <scp-hostname> <username> <filepath> <backup tar-file> command.

You can monitor the progress of the restore operation by viewing the logs at /var/log/restore.log

What to do next
• When the restore is successful, the Firepower Threat Defense device connects to the Firepower
Management Center and becomes available. The policies on the restored Firepower Threat Defense
device will be out of date. Deploy configuration changes from the Firepower Management Center to
update the policies. For more information, see Deploy Configuration Changes, on page 308.

Note If the Firepower Threat Defense Virtual device uses VPN configurations, refer
to the VPN Certificate Management section in Backup and Restore Guidelines
and Limitations, on page 162.

• Add and configure VMware interfaces. For more information, see the Cisco Firepower Threat Defense
Virtual for VMware Deployment Quick Start Guide.

Firepower Management Center Configuration Guide, Version 6.3

186
 CHAPTER 8
Configuration Import and Export
The following topics explain how to use the Import/Export feature:
• About Configuration Import/Export, on page 187
• Exporting Configurations, on page 189
• Importing Configurations, on page 190

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)

Firepower Management Center Configuration Guide, Version 6.3

187
 Firepower System Management
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 blacklists and
whitelists 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 blacklists and whitelists to user-created lists, then uses those new lists in the imported configurations.
This ensures that imported lists do not conflict with existing Global blacklists and whitelists. 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.

Firepower Management Center Configuration Guide, Version 6.3

188
 Firepower System Management
Exporting Configurations

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

Exporting Configurations
Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin

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 export icon ( ) next to list items. Where this icon is
present, you can use it as a quick alternative to the export procedure that follows.

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.

Firepower Management Center Configuration Guide, Version 6.3

189
 Firepower System Management
Importing Configurations

Click the collapse ( ) and expand ( ) icons to collapse and expand the list of available configurations.

Step 2 Check the configurations you want to export and click Export.
Step 3 Follow your web browser’s prompts to save the exported package to your computer.

Importing Configurations
Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin

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.
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 379.
If the configurations you are importing reference security zones or interface groups that do not already exist,
you can map them to existing interface objects, or create new ones.

Step 6 Click Import.

Firepower Management Center Configuration Guide, Version 6.3

190
 Firepower System Management
Import Conflict Resolution

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 191.
Step 8 Click Import.

What to do next
• Optionally, view a report summarizing the imported configurations; see Viewing Task Messages, on
page 285.

Import Conflict Resolution

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

Firepower Management Center Configuration Guide, Version 6.3

191
 Firepower System Management
Import Conflict Resolution

Resolution Option Firepower Management Center Managed Device

Duplicate in current Duplicate in ancestor or

domain descendant domain

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.

Firepower Management Center Configuration Guide, Version 6.3

192
 CHAPTER 9
Task Scheduling
The following topics explain how to schedule tasks:
• Introduction to Task Scheduling, on page 193
• Configuring a Recurring Task, on page 193
• Scheduled Task Review, on page 209

Introduction to Task Scheduling

You can schedule many different types of administrative tasks to run at designated times, either once or on a
recurring basis.

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.

Configuring a Recurring Task

Smart License Classic License Supported Devices Supported Domains Access

Any Any Task dependent Task dependent Admin/Maint

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.

Firepower Management Center Configuration Guide, Version 6.3

193
 Firepower System Management
Backup Task Automation

Procedure

Step 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.
Step 3 From the Job Type drop-down list, select the type of task that you want to schedule.
Step 4 Click the Recurring radio button 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 the up icon ( ) and the down ( ) icon to specify the interval. For
example, type 2 and click the Days radio button 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 Automating Firepower Management Center Backups,
on page 195.
• Download CRL - Schedule certificate revocation list downloads as described in Configuring Certificate
Revocation List Downloads, on page 196.
• Deploy Policies - Schedule policy deployment as described in Automating Policy Deployment, on page
197.
• Nmap Scan - Schedule Nmap scans as described in Scheduling an Nmap Scan, on page 199.
• Report - Schedule report generation as described in Automating Report Generation, on page 200
• Firepower Recommended Rules - Schedule automatic update of Firepower recommended rules as
described in Automating Firepower Recommendations, on page 202
• Download Latest Update - Schedule software or VDB update downloads as described in Automating
Software Downloads, on page 204 or Automating VDB Update Downloads, on page 207.
• 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 205 or Automating VDB
Update Installs, on page 207
• Push Latest Update - Schedule push of software updates to managed devices as described in Automating
Software Pushes, on page 204.
• Update URL Filtering Database - Scheduling automatic update of URL filtering data as described in
Automating URL Filtering Updates Using a Scheduled Task, on page 208

Backup Task Automation

You can use the scheduler to automate backup of your Firepower Management Center or physical managed
devices.

Firepower Management Center Configuration Guide, Version 6.3

194
 Firepower System Management
Automating Firepower Management Center Backups

To perform a scheduled backup of configuration data on a physical managed device, use the web interface of
the device itself.
To perform a scheduled backup of configuration and events data or configuration data only on a Firepower
Management Center, use the Firepower Management Center web interface. The backup profile you select
while scheduling the task determines the type of data backed up.
You cannot schedule a backup for a managed device from its managing Firepower Management Center, but
you can perform on-demand backups of some models of managed devices from a Firepower Management
Center.
Related Topics
Backup and Restore Support, on page 161

Automating Firepower Management Center Backups

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Global only Admin/Maint

Before you begin

• Create a backup profile. See Creating Backup Profiles, on page 170.

Procedure

Step 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.
Step 3 From the Job Type list, select Backup.
Step 4 Specify how you want to schedule the backup, 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 193 for details.

Step 5 Type a name In the Job Name field.

Step 6 From the Backup Profile list, select the appropriate backup profile.
Step 7 Optionally, type a Comment.
The comment field appears in the Task Details section of the schedule calendar page. Keep comments brief.

Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 9 Click Save.

Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1041

Firepower Management Center Configuration Guide, Version 6.3

195
 Firepower System Management
Automating Managed Device Backups

Automating Managed Device Backups

Smart License Classic License Supported Devices Supported Domains Access

Any Any 7000 & 8000 Series N/A Admin/Maint

You must perform this procedure using the 7000 or 8000 Series device's local web interface.

Before you begin

Create a backup profile. See Creating Backup Profiles, on page 170

Procedure

Step 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.
Step 3 From the Job Type list, select Backup.
Step 4 Specify how you want to schedule the backup, 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 193 for details.

Step 5 Type a name In the Job Name field.

Step 6 From the Backup Profile list, select the appropriate backup profile.
Step 7 Optionally, type a Comment.
The comment field appears in the Task Details section of the schedule calendar page. Keep comments brief.

Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 9 Click Save.

Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1041

Configuring Certificate Revocation List Downloads

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Device dependent Admin/Maint

You must perform this procedure using the local web interface for the Firepower Management Center or the
7000 or 8000 Series device. In a multidomain deployment, this task is only supported in the Global domain
for the Firepower Management Center.

Firepower Management Center Configuration Guide, Version 6.3

196
 Firepower System Management
Automating Policy Deployment

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.

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 1001 and Require Secure Connections Between
Audit Log Server and FMC, on page 1038 for more information.

Procedure

Step 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.
Step 3 From the Job Type list, select Download CRL.
Step 4 Specify how you want to schedule the CRL download, 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 193 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 1041

Automating Policy Deployment

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

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.

Firepower Management Center Configuration Guide, Version 6.3

197
 Firepower System Management
Nmap Scan Automation

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 312 and Configurations that Restart the
Snort Process When Deployed or Activated, on page 313.

Procedure

Step 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.
Step 3 From the Job Type list, select Deploy Policies.
Step 4 Specify how you want to schedule the task, 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 193 for details.

Step 5 Type a name in the Job Name field.

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 checkbox, 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.

Step 8 If you want to comment on the task, type a comment in the Comment field.
The comment field displays in the Tasks Details section of the schedule calendar page; keep comments brief.

Step 9 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 10 Click Save.

Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1041
Out-of-Date Policies, on page 318

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

Firepower Management Center Configuration Guide, Version 6.3

198
 Firepower System Management
Scheduling an Nmap Scan

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 2045

Scheduling an Nmap Scan

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

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.
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 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.
Step 3 From the Job Type list, select Nmap Scan.
Step 4 Specify how you want to schedule the task, 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 193 for details.

Step 5 Type a name in the Job Name field.

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.

Firepower Management Center Configuration Guide, Version 6.3

199
 Firepower System Management
Automating Report Generation

Step 9 If you want to comment on the task, type a comment in the Comment field.
Tip The comment field appears in the Task Details section of the calendar schedule page; keep comments
brief.

Step 10 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 11 Click Save.

Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1041

Automating Report Generation

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

You can automate reports so that they run at regular intervals.

In a multidomain deployment, you can schedule reports only for your current domain.

Before you begin

• For reports other than risk reports: Create a report template. See Report Templates, on page 2257 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 1041 and (for reports other than risk reports) Distributing Reports by Email at Generation Time, on
page 2279 or (for risk reports) Generating, Viewing, and Printing Risk Reports, on page 2255.
• (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 201.
• 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 2257.

Procedure

Step 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.
Step 3 From the Job Type list, select Report.
Step 4 Specify how you want to schedule the task, 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 193 for details.

Firepower Management Center Configuration Guide, Version 6.3

200
 Firepower System Management
Specify Report Generation Settings for a Scheduled Report

Step 5 Type a name in the Job Name field.

Step 6 In the Report Template field, select a risk report or report template.
Step 7 If you want to comment on the task, type a comment in the Comment field.
The comment field appears in the Tasks Details section of the schedule calendar page; keep comments brief.

Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Note Configuring this option does not distribute the reports.

Step 9 If you do not want to receive report email attachments when reports have no data (for example, when no
events of a certain type occurred during the report period), select the If report is empty, still attach to email
check box.
Step 10 Click Save.

Specify Report Generation Settings for a Scheduled Report

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Any Security

Analyst

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.
Step 4 Click Generate.
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.

Firepower Management Center Configuration Guide, Version 6.3

201
 Firepower System Management
Automating Firepower Recommendations

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

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Maint

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.

Before you begin

• Configure Firepower recommended rules in an intrusion policy as described in Generating and Applying
Firepower Recommendations, on page 1706
• If you want to email task status messages, configure a valid email relay server.

Procedure

Step 1 Choose System > Tools > Scheduling.

Step 2 Click Add Task.
Step 3 From the Job Type list, choose Firepower Recommended Rules.
Step 4 Specify how you want to schedule the task, 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 193 for details.

Step 5 Enter a name in the Job Name field.

Firepower Management Center Configuration Guide, Version 6.3

202
 Firepower System Management
Software Update Automation

Step 6 Next to Policies, choose one or more intrusion policies where you want to generate recommendations. Check
the 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 1648
About Firepower Recommended Rules, on page 1703
Configuring a Mail Relay Host and Notification Address, on page 1041

Software Update Automation

You can automatically download and apply most patches and feature releases to the Firepower System.
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.

Firepower Management Center Configuration Guide, Version 6.3

203
 Firepower System Management
Automating Software Downloads

Note that a task scheduled to install an update on a device group will install the pushed update to each device
within the device group simultaneously. Allow enough time for the scheduled task to complete for each device
within the device group.
If you want to have more control over this process, you can use the Once option to download and install
updates during off-peak hours after you learn that an update has been released.
Related Topics
Management Interfaces, on page 1006
About Firepower Updates, on page 145

Automating Software Downloads

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Global only Admin/Maint

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

Step 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.
Step 3 From the Job Type list, select Download Latest Update.
Step 4 Specify how you want to schedule the task, 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 193 for details.

Step 5 Type a name in the Job Name field.

Step 6 Next to Update Items, check the Software check box.
Step 7 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 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 9 Click Save.

Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1041

Automating Software Pushes

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Global only Admin/Maint

Firepower Management Center Configuration Guide, Version 6.3

204
 Firepower System Management
Automating Software Installs

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 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.
Step 3 From the Job Type list, select Push Latest Update.
Step 4 Specify how you want to schedule the task, 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 193 for details.

Step 5 Type a name in the Job Name field.

Step 6 From the Device drop-down list, select the device that you want to update.
Step 7 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 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 9 Click Save.

Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1041

Automating Software Installs

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Global only Admin/Maint

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 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.

Firepower Management Center Configuration Guide, Version 6.3

205
 Firepower System Management
Vulnerability Database Update Automation

Step 3 From the Job Type list, select Install Latest Update.
Step 4 Specify how you want to schedule the task, 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 193 for details.

Step 5 Type a name in the Job Name field.

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.
Step 8 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 9 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 10 Click Save.

Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1041

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.
When automating VDB updates, you must automate two separate steps:
• Downloading the VDB update.
• Installing the VDB 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 312 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:

Firepower Management Center Configuration Guide, Version 6.3

206
 Firepower System Management
Automating VDB Update Downloads

• You cannot schedule updates for appliances that cannot access the Support Site. If your FMC is not
directly connected to the Internet, you should use management interfaces configuration to set up a proxy
to allow it to download updates from the Support Site.
• If you want to have more control over this process, you can use the Once option to download and install
VDB updates during off-peak hours after you learn that an update has been released.
• In multidomain deployments, you can only schedule VDB updates for the Global domain. The changes
take effect when you redeploy policies.

Related Topics
Management Interfaces, on page 1006

Automating VDB Update Downloads

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Global only Admin/Maint

Procedure

Step 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.
Step 3 From the Job Type list, select Download Latest Update.
Step 4 Specify how you want to schedule the task, 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 193 for details.

Step 5 Type a name in the Job Name field.

Step 6 Next to Update Items, check the Vulnerability Database check box.
Step 7 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 calendar schedule page; keep comments brief.

Step 8 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 9 Click Save.

Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1041

Automating VDB Update Installs

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Global only Admin/Maint

Firepower Management Center Configuration Guide, Version 6.3

207
 Firepower System Management
Automating URL Filtering Updates Using a Scheduled Task

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 312 for more information.

Procedure

Step 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.
Step 3 From the Job Type list, select Install Latest Update.
Step 4 Specify how you want to schedule the task, 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 193 for details.

Step 5 Type a name in the Job Name field.

Step 6 From the Device drop-down list, select the FMC.
Step 7 Next to Update Items, check the Vulnerability Database check box.
Step 8 If you want to comment on the task, type a comment in the Comment field.
Tip The comment field appears in the View Tasks section of the page, so you should try to keep it
relatively short.

Step 9 If you want to email task status messages, type an email address (or multiple email addresses separated by
commas) in the Email Status To: field. You must have a valid email relay server configured to send status
messages.
Step 10 Click Save.

Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1041

Automating URL Filtering Updates Using a Scheduled Task

Smart License Classic License Supported Devices Supported Domains Access

URL Filtering URL Filtering Any Global only Admin/Maint

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.

Firepower Management Center Configuration Guide, Version 6.3

208
 Firepower System Management
Scheduled Task Review

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 2679.
• Ensure that URL filtering is enabled. See Enable URL Filtering Using Category and Reputation, on page
1394 for more information.
• Verify that Enable Automatic Updates is not selected on the Cisco CSI tab under the System >
Integration menu.

Procedure

Step 1 Select System > Tools > Scheduling.

Step 2 Click Add Task.
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:
• 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 193 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 to send status
messages.
Step 8 Click Save.

Related Topics
Configuring a Mail Relay Host and Notification Address, on page 1041

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.

Firepower Management Center Configuration Guide, Version 6.3

209
 Firepower System Management
Task List Details

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 17: 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.

Last Run Status Describes the current status for a scheduled task:

• A check mark icon ( ) indicates that the task

ran successfully.

• A question mark icon ( ) 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.

Firepower Management Center Configuration Guide, Version 6.3

210
 Firepower System Management
Viewing Scheduled Tasks on the Calendar

Column Description

Delete Deletes the scheduled task.

Viewing Scheduled Tasks on the Calendar

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

In a multidomain deployment, you can view scheduled tasks only for your current domain.

Procedure

Step 1 Select System > Tools > Scheduling.

Step 2 You can perform the following tasks using the calendar view:

• Click the double left arrow icon ( ) to move back one year.

• Click the single left arrow icon ( ) to move back one month.

• Click the single right arrow icon ( ) to move forward one month.

• Click the double right arrow icon ( ) 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.
• Click a specific task on a date to view the task in a task list table below the calendar.

Editing Scheduled Tasks

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

In a multidomain deployment, you can edit scheduled tasks only for your current domain.

Procedure

Step 1 Select System > Tools > Scheduling.

Step 2 On the calendar, click either the task that you want to edit or the day on which the task appears.

Firepower Management Center Configuration Guide, Version 6.3

211
 Firepower System Management
Deleting Scheduled Tasks

Step 3 In the Task Details table, click the edit icon ( ) next to the task you want to edit.
Step 4 Edit the task.
Step 5 Click Save.

Deleting Scheduled Tasks

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

In a multidomain deployment, you can delete scheduled tasks only for your current domain.

Procedure

Step 1 Select System > Tools > Scheduling.

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 the delete icon ( ), then confirm your choice.

Firepower Management Center Configuration Guide, Version 6.3

212
 CHAPTER 10
FMC Database Purge
The following topic describes how to purge discovery data from the FMC:
• Purging Data from the FMC Database, on page 213

Purging Data from the FMC Database

Smart License Classic License Supported Domains Access

Any Any Global only Admin/Security Analyst

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.

Procedure

Step 1 Choose System > Tools > Data Purge.

Step 2 Under Network Discovery, 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.

Firepower Management Center Configuration Guide, Version 6.3

213
 Firepower System Management
Purging Data from the FMC 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.

Firepower Management Center Configuration Guide, Version 6.3

214
PA R T III
System Monitoring and Troubleshooting
• Dashboards, on page 217
• Health Monitoring, on page 239
• Monitoring the System, on page 267
• Troubleshooting the System, on page 279
 CHAPTER 11
Dashboards
The following topics describe how to use dashboards in the Firepower System:
• About Dashboards, on page 217
• Firepower System Dashboard Widgets, on page 218
• Managing Dashboards, on page 230

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. Dashboards are
available on the Firepower Management Center and 7000 & 8000 Series devices.

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.

Firepower Management Center Configuration Guide, Version 6.3

217
 System Monitoring and Troubleshooting
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 30.
Note that:

Firepower Management Center Configuration Guide, Version 6.3

218
 System Monitoring and Troubleshooting
Dashboard Widget Availability by User Role

• 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 18: 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

Interface Traffic yes yes yes yes

Firepower Management Center Configuration Guide, Version 6.3

219
 System Monitoring and Troubleshooting
Predefined Dashboard Widgets

Widget Administrator Maintenance User Security Analyst Security Analyst

(RO)

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

White 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.

Firepower Management Center Configuration Guide, Version 6.3

220
 System Monitoring and Troubleshooting
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, stacked,
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

Firepower Management Center Configuration Guide, Version 6.3

221
 System Monitoring and Troubleshooting
The Current Sessions Widget

• gray: link is administratively disabled

• 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 widget preferences control how often the widget updates.

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)

Firepower Management Center Configuration Guide, Version 6.3

222
System Monitoring and Troubleshooting
The Custom Analysis Widget

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.
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 ( ) 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.

Firepower Management Center Configuration Guide, Version 6.3

223
 System Monitoring and Troubleshooting
Custom Analysis Widget Preferences

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
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 236

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 19: 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.

Firepower Management Center Configuration Guide, Version 6.3

224
 System Monitoring and Troubleshooting
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 233

Viewing Associated Events from the Custom Analysis Widget

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Any Security

Analyst/Maint

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.

Firepower Management Center Configuration Guide, Version 6.3

225
 System Monitoring and Troubleshooting
The Disk Usage Widget

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

Procedure

You have the following choices:

• On any Custom Analysis widget, click the view all icon ( ) 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 20: 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.

Firepower Management Center Configuration Guide, Version 6.3

226
 System Monitoring and Troubleshooting
The Interface Traffic Widget

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.

The Interface Traffic Widget

The Interface Traffic widget shows the rate of traffic received (Rx) and transmitted (Tx) on the appliance’s
management interface. For 7000 & 8000 Series devices, the widget also shows information on the sensing
interfaces. The widget does not appear by default on any of the predefined dashboards.
Outbound (transmitted) traffic includes flow control packets. Because of this, passive sensing interfaces on
7000 & 8000 Series devices may show transmitted traffic; this is expected behavior. 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 also expected behavior.
The widget preferences control how often the widget updates. On 7000 & 8000 Series devices, the preferences
also control whether the widget displays the traffic rate for unused interfaces (by default, the widget only
displays the traffic rate for active interfaces).

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 2489. The arrow (if any) that
appears above the impact level numbers describes the inline result and is defined as follows:

Table 21: Inline Result Field Contents in Workflow and Table Views

This Icon Indicates

A black down arrow The system dropped the packet that triggered the rule

A gray down arrow IPS would have dropped the packet if you enabled the Drop when Inline
intrusion policy option (in an inline deployment), or if a Drop and Generate
rule generated the event while the system was pruning

No icon (blank) The triggered rule was not set to Drop and Generate Events

In a passive deployment, the system does not drop packets, including when an inline interface is in tap
mode, regardless of the rule state or the inline drop behavior of the intrusion policy.
• Show to specify Average Events Per Second (EPS) or Total Events.
• Vertical Scale to specify Linear (incremental) or Logarithmic (factor of ten) scale.
• How often the widget updates.

On the widget, you can:

Firepower Management Center Configuration Guide, Version 6.3

227
 System Monitoring and Troubleshooting
The Network Compliance Widget

• 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.
• 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 white 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 white 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 white lists or for a specific white
list by modifying the widget preferences.
If you choose to display network compliance for all white lists, the widget considers a host to be non-compliant
if it is not compliant with any white 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 white 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.

Firepower Management Center Configuration Guide, Version 6.3

228
 System Monitoring and Troubleshooting
The Product Updates Widget

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.

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.
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 the update icon ( ) 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.

Firepower Management Center Configuration Guide, Version 6.3

229
 System Monitoring and Troubleshooting
The System Time Widget

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.

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 White List Events Widget

The White 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 white 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 white 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 white list events of a specific priority, or click the All graph to view all white
list events. In either case, the events are constrained by the dashboard time range; accessing white list events
via the dashboard changes the events (or global) time window for the Firepower Management Center.

Managing Dashboards
Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Any Security

Analyst/Maint

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 233.
• Delete Dashboards — To delete a dashboard, click the delete icon ( ) 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 235.

Firepower Management Center Configuration Guide, Version 6.3

230
 System Monitoring and Troubleshooting
Adding a Dashboard Tab

• Modify Time Constraints — Modify the time display or pause/unpause the dashboard as described in
Modifying Dashboard Time Settings, on page 236.

Step 3 Manage dashboard tabs:

• Add Tabs — Add a tab to a dashboard; see Adding a Dashboard Tab, on page 231.
• Delete Tabs — To delete a dashboard tab, click the close icon ( ) in the top right corner of the tab, and
confirm by clicking OK . You cannot delete the last tab from a dashboard; each dashboard must have at
least one tab.
• Rename Tabs — Rename a tab in a dashboard; see Renaming a Dashboard Tab, on page 237.
Note You cannot change the order of dashboard tabs.

Step 4 Manage dashboard widgets:

• Add Widgets — Add widgets to a dashboard; see Adding Widgets to a Dashboard, on page 232.
• Configure Preferences — Configure widget preferences; see Configuring Widget Preferences, on page
233.
• Customize Display — Customize the widget display; see Customizing the Widget Display, on page 235.
• View Events — View associated events from the Custom Analysis Widget; see Viewing Associated
Events from the Custom Analysis Widget, on page 225.
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 Tab

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Any Security

Analyst/Maint

Procedure

Step 1 View the dashboard you want to modify; see Viewing Dashboards, on page 237.

Step 2 Click the add icon ( ) next to the last existing tab.
Step 3 Enter a name for the tab.
Step 4 Click OK.

Firepower Management Center Configuration Guide, Version 6.3

231
 System Monitoring and Troubleshooting
Adding Widgets to a Dashboard

Adding Widgets to a Dashboard

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Any Security

Analyst/Maint

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 237.
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 233.

Related Topics
Widget Availability, on page 218

Firepower Management Center Configuration Guide, Version 6.3

232
 System Monitoring and Troubleshooting
Configuring Widget Preferences

Configuring Widget Preferences

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Any Security

Analyst/Maint

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 the show preferences icon ( ).
Step 2 Make changes as needed.
Step 3 On the widget title bar, click the hide preferences icon ( ) to hide the preferences section.

Creating Custom Dashboards

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Any Security

Analyst/Maint

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 233.
Step 4 Click Save.

Custom Dashboard Options

The table below describes options you can use when creating or editing custom dashboards.

Firepower Management Center Configuration Guide, Version 6.3

233
 System Monitoring and Troubleshooting
Custom Dashboard Options

Table 22: 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.

Refresh Page Every Specifies (in minutes) how often the current dashboard tab should
refresh with new data. 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. 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. Note that you do not need to refresh the entire
dashboard to see data updates; individual widgets update according
to their preferences.
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.

Firepower Management Center Configuration Guide, Version 6.3

234
 System Monitoring and Troubleshooting
Customizing the Widget Display

Option Description

Save As Private Determines whether the custom dashboard can be viewed and
modified by all users of the appliance or is associated with your
user account and reserved solely for your own use. Keep in mind
that any user with dashboard access, regardless of role, can modify
shared dashboards. If you want to make sure that only you can
modify a particular dashboard, save it as private.

Customizing the Widget Display

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Any Security

Analyst/Maint

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 237.

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.
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 the minimize ( ) or maximize icon ( ) in
a widget’s title bar.
• To delete a widget if you no longer want to view it on a tab, click the close icon ( ) in the title bar of
the widget.

Editing Dashboards Options

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Any Security

Analyst/Maint

Firepower Management Center Configuration Guide, Version 6.3

235
 System Monitoring and Troubleshooting
Modifying Dashboard Time Settings

Procedure

Step 1 View the dashboard you want to edit; see Viewing Dashboards, on page 237.

Step 2 Click the edit icon ( ) next to the dashboard you want to modify.
Step 3 Change the options as described in Custom Dashboard Options, on page 233.
Step 4 Click Save.

Modifying Dashboard Time Settings

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Any Security

Analyst/Maint

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.
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.
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.

Firepower Management Center Configuration Guide, Version 6.3

236
 System Monitoring and Troubleshooting
Renaming a Dashboard Tab

Procedure

Step 1 View the dashboard where you want to add a widget; see Viewing Dashboards, on page 237.
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 the pause ( ) or play icon ( ).

Renaming a Dashboard Tab

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Any Security

Analyst/Maint

Procedure

Step 1 View the dashboard you want to modify; see Viewing Dashboards, on page 237.
Step 2 Click the tab title you want to rename.
Step 3 Type a name for the tab.
Step 4 Click OK.

Viewing Dashboards
Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Any Security

Analyst/Maint

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.

Firepower Management Center Configuration Guide, Version 6.3

237
 System Monitoring and Troubleshooting
Viewing Dashboards

• To view all available dashboards, choose Overview > Dashboards > Management. You can then choose
the view icon ( ) next to an individual dashboard to view it.

Firepower Management Center Configuration Guide, Version 6.3

238
 CHAPTER 12
Health Monitoring
The following topics describe how to use health monitoring in the Firepower System:
• About Health Monitoring, on page 239
• Health Policies, on page 248
• The Health Monitor Blacklist, on page 251
• Health Monitor Alerts, on page 253
• Using the Health Monitor, on page 256
• Viewing Appliance Health Monitors, on page 258
• Health Event Views, on page 261
• History for Health Monitoring, on page 266

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

239
 System Monitoring and Troubleshooting
Health Modules

Note All Appliances automatically report their hardware status via the Hardware Alarms health module. The
Firepower Management Center also automatically reports status using the modules configured in the default
health policy. Some health modules, such as the Appliance Heartbeat module, run on the Firepower Management
Center and report the status of the Firepower Management Center's managed devices. Some health modules
do not provide managed device status unless you apply a health policy configured with those modules to a
device.

You can use the health monitor to access health status information for the entire system, for a particular
appliance, or, in a multidomain deployment, a particular domain. Pie charts and status tables on the Health
Monitor page provide a visual summary of the status of all appliances on your network, including the Firepower
Management Center. Individual appliance health monitors let you drill down into health details for a specific
appliance.
Fully customizable event views allow you to quickly and easily analyze the health status events gathered by
the health monitor. These event views allow you to search and view event data and to access other information
that may be related to the events you are investigating. For example, if you want to see all the occurrences of
CPU usage with a certain percentage, you can search for the CPU usage module and enter the percentage
value.
You can also configure email, SNMP, or syslog alerting in response to health events. A health alert is an
association between a standard alert and a health status level. For example, if you need to make sure an
appliance never fails due to hardware overload, you can set up an email alert. You can then create a health
alert that triggers that email alert whenever CPU, disk, or memory usage reaches the Warning level you
configure in the health policy applied to that appliance. You can set alerting thresholds to minimize the number
of repeating alerts you receive.
You can also generate troubleshooting files for an appliance if you are asked to do so by Support.
Because health monitoring is an administrative activity, only users with administrator user role privileges can
access system health data.

Health Modules
Health modules, or health tests, test for the criteria you specify in a health policy.

Table 23: Health Modules

Module Appliances Description

AMP for Endpoints FMC The module alerts if the Firepower Management Center cannot connect to the
Status AMP cloud or Cisco 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.

Firepower Management Center Configuration Guide, Version 6.3

240
 System Monitoring and Troubleshooting
Health Modules

Module Appliances Description

AMP for Firepower FMC This module alerts if:

Status
• The Firepower Management Center cannot contact the AMP cloud (public
(AMP for Networks or private) or the Cisco Threat Grid public cloud or on-premises appliance,
Status) or the AMP private 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 Firepower Management Center loses connectivity to the Internet, the

system may take up to 30 minutes to generate an AMP for Firepower Status
health alert.

Appliance Heartbeat Any This module determines if an appliance heartbeat is being heard from the
appliance and alerts based on the appliance heartbeat status.

Automatic Application 7000 & 8000 Series This module determines if an appliance has been bypassed because it did not
Bypass Status respond within the number of seconds set in the bypass threshold, and alerts
when a bypass occurs.
Backlog Status FMC This module displays an alert if the backlog of event data awaiting transmission
from the device to the FMC has grown continuously for more than 30 minutes.
To reduce the backlog, evaluate your bandwidth and consider logging fewer
events.

Classic License Monitor FMC This module determines if sufficient Classic licenses for Control, Protection,
URL Filtering, Malware, and VPN remain. It also alerts when devices in a
stack have mismatched license sets. It alerts based on a warning level
automatically configured for the module. You cannot change the configuration
of this module.

CPU Usage Any This module checks that the CPU on the appliance is not overloaded and alerts
when CPU usage exceeds the percentages configured for the module.

Card Reset Any This module checks for network cards which have restarted due to hardware
failure and alerts when a reset occurs.

Cluster Status Threat Defense This module monitors the status of device clusters. The module alerts if:
• A new primary unit is elected to a cluster.
• A new secondary unit joins a cluster.
• A primary or secondary unit leaves a cluster.

Firepower Management Center Configuration Guide, Version 6.3

241
 System Monitoring and Troubleshooting
Health Modules

Module Appliances Description

Disk Status Any This module examines performance of the hard disk, and malware storage pack
(if installed) on the appliance. This module generates a Warning (yellow) health
alert when the hard disk and RAID controller (if installed) are in danger of
failing, or if an additional hard drive is installed that is not a malware storage
pack. This module generates an Alert (red) health alert when an installed
malware storage pack cannot be detected.

Disk Usage Any This module compares disk usage on the appliance’s hard drive and malware
storage pack to the limits configured for the module and alerts when usage
exceeds the percentages configured for the module. This module also alerts
when the system excessively deletes files in monitored disk usage categories,
or when disk usage excluding those categories reaches excessive levels, based
on module thresholds. Use the Disk Usage health status module to monitor
disk usage for the / and /volume partitions on the appliance and track draining
frequency. Although the disk usage module lists the /boot partition as a
monitored partition, the size of the partition is static so the module does not
alert on the boot partition.

Host Limit FMC This module determines if the number of hosts the Firepower Management
Center 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 2023.

Hardware Alarms 7000 & 8000 Series, This module determines if hardware needs to be replaced on a physical managed
Threat Defense device and alerts based on the hardware status. The module also reports on the
(physical) status of hardware-related daemons and on the status of 7000 and 8000 Series
devices in high-availability deployments.

HA Status FMC This module monitors and alerts on the high availability status of the Firepower
Management Center. If you have not established Firepower Management Center
high availability, the HA Status is Not in HA.
This module does not monitor or alert on the high availability status of managed
devices, regardless of whether they are paired. The HA Status for a managed
device is always Not in HA. Use the device management page Devices >
Device Management to monitor devices in high availability pairs.

Health Monitor Process Any This module monitors the status of the health monitor itself and alerts if the
number of minutes since the last health event received by the Firepower
Management Center exceeds the Warning or Critical limits.

Inline Link Mismatch Any managed device This module monitors the ports associated with inline sets and alerts if the two
Alarms except ASA FirePOWER interfaces of an inline pair negotiate different speeds.

Firepower Management Center Configuration Guide, Version 6.3

242
 System Monitoring and Troubleshooting
Health Modules

Module Appliances Description

Intrusion and File Event Any managed device This module compares the number of intrusion events per second to the limits
Rate configured for this module and alerts if the limits are exceeded. If the Intrusion
and File Event Rate is zero, the intrusion process may be down or the managed
device may not be sending events. Select Analysis > Intrusions > Events to
check if events are being received from the device.
Typically, the event rate for a network segment averages 20 events per second.
For a network segment with this average rate, Events per second (Critical)
should be set to 50 and Events per second (Warning) should be set to 30. To
determine limits for your system, find the Events/Sec value on the Statistics
page for your device (System > Monitoring > Statistics), then calculate the
limits using these formulas:
• Events per second (Critical) = Events/Sec * 2.5
• Events per second (Warning) = Events/Sec * 1.5

The maximum number of events you can set for either limit is 999, and the
Critical limit must be higher than the Warning limit.

Interface Status Any This module determines if the device currently collects traffic and alerts based
on the traffic status of physical interfaces and aggregate interfaces. For physical
interfaces, the information includes interface name, link state, and bandwidth.
For aggregate interfaces, the information includes interface name, number of
active links, and total aggregate bandwidth.
For ASA FirePOWER, interfaces labeled DataPlaneInterfacex, where x is a
numerical value, are internal interfaces (not user-defined) and involve packet
flow within the system.

Link State Propagation Any except NGIPSv, This module determines when a link in a paired inline set fails and triggers the
ASA FirePOWER, link state propagation mode.
Firepower 9300,
If a link state propagates to the pair, the status classification for that module
Firepower 4100 series,
changes to Critical and the state reads:
Firepower 2100 series
Module Link State Propagation: ethx_ethy is Triggered

where x and y are the paired interface numbers.

Local Malware Analysis Any This module alerts if a device running a version earlier than 6.3 is configured
for local malware analysis and fails to download local malware analysis engine
signature updates from the AMP cloud.
For devices running version 6.3 or higher, see the Threat Data Updates on
Devices module.

Firepower Management Center Configuration Guide, Version 6.3

243
 System Monitoring and Troubleshooting
Health Modules

Module Appliances Description

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 4GB of memory, the preset alert thresholds are
based on a formula that accounts for proportions of available memory likely
to cause system problems. On >4GB 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.
Complex access control policies and rules can command significant resources
and negatively affect performance. Some lower-end ASA devices with
FirePOWER Services Software may generate intermittent memory usage
warnings, as the device’s memory allocation is being used to the fullest extent
possible.

Platform Faults Firepower 2100 On Firepower 2100 devices, a fault is a mutable object that is managed by the
Firepower Management Center. Each fault represents a failure in the Firepower
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 2100 FXOS Faults and Error
Messages Guide.

Power Supply Physical FMCs,7000 & This module determines if power supplies on the device require replacement
8000 Series and alerts based on the power supply status.
Note If an 8000 Series managed device experiences a power failure, it
may take up to 20 minutes to generate an alert.

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.

Reconfiguring Detection Any managed device This module alerts if a device reconfiguration has failed.

RRD Server Process FMC This module determines if the round robin data server that stores time series
data is running properly. The module will alert If the RRD server has restarted
since the last time it updated; it will enter Critical or Warning status if the
number of consecutive updates with an RRD server restart reaches the numbers
specified in the module configuration.

Firepower Management Center Configuration Guide, Version 6.3

244
 System Monitoring and Troubleshooting
Health Modules

Module Appliances Description

Security Intelligence FMC and some managed This module alerts if Security Intelligence is in use and:
devices
• The Firepower Management Center cannot update a feed, or feed data is
corrupt or contains no recognizable IP addresses.
• A managed device that is running a release earlier than 6.3 had a problem
receiving updated Security Intelligence data from the Firepower
Management Center.
• A managed device that is running a release earlier than 6.3 cannot load
all of the Security Intelligence data provided to it by the Firepower
Management Center due to memory issues; see Troubleshooting Memory
Use, on page 1410.
• For managed devices running version 6.3 or higher, see 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 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.

Firepower Management Center Configuration Guide, Version 6.3

245
 System Monitoring and Troubleshooting
Health Modules

Module Appliances Description

Threat Data Updates on FMC and devices Certain intelligence data and configurations that devices use to detect threats
Devices running release 6.3 and are updated on the Firepower Management Center from the cloud every 30
later. minutes.
(For devices running a This module alerts you if this information has not been updated on the devices
version earlier than 6.3, within the time period you have specified.
see information in this
Monitored updates include:
table about the Security
Intelligence, URL • Local URL category and reputation data
Filtering, and Local
Malware Analysis health • Security Intelligence URL lists and feeds, including global whitelists and
modules.) blacklists and URLs from Threat Intelligence Director
• Security Intelligence network lists and feeds (IP addresses), including
global whitelists and blacklists and IP addresses from Threat Intelligence
Director
• Security Intelligence DNS lists and feeds, including global whitelists and
blacklists 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
> Cisco CSI page. (Updates to the URL cache are not monitored by this
module.)

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
Firepower Management Center 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 1410.

Time Series Data Monitor FMC This module tracks the presence of corrupt files in the directory where time
series data (such as correlation event counts) are stored and alerts when files
are flagged as corrupt and removed.

Time Synchronization Any This module tracks the synchronization of a device clock that obtains time
Status using NTP with the clock on the NTP server and alerts if the difference in the
clocks is more than ten seconds.

Firepower Management Center Configuration Guide, Version 6.3

246
 System Monitoring and Troubleshooting
Configuring Health Monitoring

Module Appliances Description

URL Filtering Monitor FMCs This module alerts if the Firepower Management Center fails to:
For devices running • Communicate with, or retrieve a URL threat intelligence data update from,
version 6.3 or higher, see Cisco Collective Security Intelligence (CSI).
also the Threat Data
Updates on Devices • For devices running versions earlier than 6.3: Push URL threat data to its
module. managed devices. (For devices running version 6.3 or later, configure
alerts for this problem in the Threat Data Updates on Devices module.)

User Agent Status FMC This module alerts when heartbeats are not detected for any User Agents
Monitor connected to the Firepower Management Center.

VPN Status FMC This module alerts when one or more VPN tunnels between Firepower System
devices are down.
This module tracks:
• VPN for 7000 & 8000 Series devices)
• Site-to-site VPN for Firepower Threat Defense
• Remote access VPN for Firepower Threat Defense

Configuring Health Monitoring

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

Procedure

Step 1 Determine which health modules you want to monitor as discussed in Health Modules, on page 240.
You can set up specific policies for each kind of appliance you have in your Firepower System, enabling only
the appropriate tests for that appliance.
Tip To quickly enable health monitoring without customizing the monitoring behavior, you can apply
the default policy provided for that purpose.

Step 2 Apply a health policy to each appliance where you want to track health status as discussed in Creating Health
Policies, on page 248.
Step 3 (Optional.) Configure health monitor alerts as discussed in Creating Health Monitor Alerts, on page 254.
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.

Firepower Management Center Configuration Guide, Version 6.3

247
 System Monitoring and Troubleshooting
Health Policies

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 health monitor on the Firepower Management Center provides a default health policy to allow you to
quickly implement health monitoring for your appliances. In the default health policy, most of the health
modules available on the running platform are automatically enabled. The default health policy is automatically
applied to the Firepower Management Center. Additionally, the default health policy is applied to a managed
device when you add the device to the Firepower Management Center. You cannot edit the default health
policy, but you can copy it to create custom policies based on its configuration.

Creating Health Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

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.
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 Create 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.

Firepower Management Center Configuration Guide, Version 6.3

248
 System Monitoring and Troubleshooting
Applying Health Policies

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 249. This
applies your changes and updates the policy status for all affected policies.

Applying Health Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

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.
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 the apply icon ( ) next to the policy you want to apply.

Firepower Management Center Configuration Guide, Version 6.3

249
 System Monitoring and Troubleshooting
Editing Health Policies

Tip
The status icon ( ) 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 285.
Monitoring of the appliance starts as soon as the policy is successfully applied.

Editing Health Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

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 the edit icon ( ) 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 Health Modules, on page 240.
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.

What to do next
• Reapply the health policy as described in Applying Health Policies, on page 249. This applies your changes
and updates the policy status for all affected policies.

Firepower Management Center Configuration Guide, Version 6.3

250
 System Monitoring and Troubleshooting
Deleting Health Policies

Deleting Health Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

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 1 Choose System > Health > Policy .

Step 2 Click the delete icon ( ) next to the policy you want to delete.
A message appears, indicating if the deletion was successful.

The Health Monitor Blacklist

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 blacklist 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
blacklist, the events that were generated during the blacklisting continue to show a status of disabled.
To temporarily disable health events from an appliance, go to the blacklist configuration page and add an
appliance to the blacklist. After the setting takes effect, the system no longer includes the blacklisted appliance
when calculating the overall health status. The Health Monitor Appliance Status Summary lists the appliance
as disabled.
At times it may be more practical to just blacklist an individual health monitoring module on an appliance.
For example, when you reach the host limit on a Firepower Management Center, you can blacklist the Host
Limit status messages.

Firepower Management Center Configuration Guide, Version 6.3

251
 System Monitoring and Troubleshooting
Blacklisting Appliances

Note that on the main Health Monitor page you can distinguish between appliances that are blacklisted if you
expand to view the list of appliances with a particular status by clicking the arrow in that status row.

A blacklist icon ( ) and a notation are visible after you expand the view for a blacklisted or partially blacklisted
appliance.

Note On a Firepower Management Center, Health Monitor blacklist settings are local configuration settings.
Therefore, if you blacklist a device, then delete it and later re-register it with the Firepower Management
Center, the blacklist settings remain persistent. The newly re-registered device remains blacklisted.

In a multidomain deployment, administrators in ancestor domains can blacklist an appliance or health module
in descendant domains. However, administrators in the descendant domains can override the ancestor
configuration and clear the blacklist for devices in their domain.

Blacklisting Appliances
Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

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 appliance group, model, or by policy.
Tip
The status icon next to the Health Policy column ( ) indicates the current health status for the
appliance. The status icon next to the System Policy column ( ) 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.

Firepower Management Center Configuration Guide, Version 6.3

252
 System Monitoring and Troubleshooting
Blacklisting Health Policy Modules

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

Blacklisting Health Policy Modules

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint

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 the edit icon ( ) 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 Health Modules, on page 240.
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.

Firepower Management Center Configuration Guide, Version 6.3

253
 System Monitoring and Troubleshooting
Health Monitor Alert Information

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.
• Description, which includes the health test results that triggered the alert.

The table below describes these severity levels.

Table 24: 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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin

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.
In a multidomain deployment, you can view and modify health monitor alerts created in the current domain
only.

Firepower Management Center Configuration Guide, Version 6.3

254
 System Monitoring and Troubleshooting
Editing Health Monitor Alerts

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 2285.

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.
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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin

You can edit existing health monitor alerts to change the severity level, health module, or alert response
associated with the health monitor alert.
In a multidomain deployment, you can view and modify health monitor alerts created in the current domain
only.

Procedure

Step 1 Choose System > Health > Monitor Alerts.

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.

Firepower Management Center Configuration Guide, Version 6.3

255
 System Monitoring and Troubleshooting
Deleting Health Monitor Alerts

Deleting Health Monitor Alerts

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin

In a multidomain deployment, you can view and modify health monitor alerts created in the current domain
only.

Procedure

Step 1 Choose System > Health > Monitor Alerts.

Step 2 Choose the active health alerts you want to delete, then click Delete.

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 2285.

Using the Health Monitor

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint/Any

Security Analyst

The health monitor provides the compiled health status for all devices managed by the Firepower Management
Center, plus the Firepower Management Center. The health monitor is composed of:
• The status table — Provides a count of the managed appliances for this Firepower Management Center
by overall health status.
• The pie chart — Indicates the percentage of appliances currently in each health status category.
• The appliance list — Provides details on the health of the managed devices.

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 Choose the appropriate status in the Status column of the table or the appropriate portion of the pie chart to
the list appliances with that status.

Firepower Management Center Configuration Guide, Version 6.3

256
 System Monitoring and Troubleshooting
Health Monitor Status Categories

Tip If the arrow in the row for a status level points down, the appliance list for that status shows in the
lower table. If the arrow points right, the appliance list is hidden.

Step 3 You have the following choices:

• View appliance health monitors; see Viewing Appliance Health Monitors, on page 258.
• Create health policies; see Creating Health Policies, on page 248.
• Create health monitor alerts; see Creating Health Monitor Alerts, on page 254.

Health Monitor Status Categories

Available status categories are listed by severity in the table below.

Table 25: Health Status Indicator

Status Level Status Icon Status Color in Pie Chart Description

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 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 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 are running
within the limits configured in
the health policy applied to the
appliance.

Firepower Management Center Configuration Guide, Version 6.3

257
 System Monitoring and Troubleshooting
Viewing Appliance Health Monitors

Status Level Status Icon Status Color in Pie Chart Description

Recovered Green Indicates that all health modules

on the appliance 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, that the
appliance does not have a health
policy applied to it, or that the
appliance is currently
unreachable.

Viewing Appliance Health Monitors

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint/Any

Security Analyst

The Appliance Health Monitor provides a detailed view of the health status of an appliance.
In a multidomain deployment, you can view the health status of appliances in descendant domains.

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, on page 47 and
Configuring Session Timeouts, on page 1052 for more information.

Procedure

Step 1 Choose System > Health > Monitor.

Step 2 Expand the appliance list. To show appliances with a particular status, click the arrow in that status row.
Alternatively, in the Appliance Status Summary graph, click the color for the appliance status category you
want to view.
Tip If the arrow in the row for a status level points down, the appliance list for that status shows in the
lower table. If the arrow points right, the appliance list is hidden.

Step 3 In the Appliance column of the appliance list, click the name of the appliance for which you want to view
details.

Firepower Management Center Configuration Guide, Version 6.3

258
 System Monitoring and Troubleshooting
Running All Modules for an Appliance

Tip In the Module Status Summary graph, click the color for an event status category to toggle display
of Alert Details for that status category.

What to do next
• If you want to run all health modules for the appliance, see Running All Modules for an Appliance, on
page 259
• If you want to run a specific health module for an appliance, see Running a Specific Health Module, on
page 260
• If you want to generate health module alert graphs for the appliance, see Generating Health Module Alert
Graphs, on page 260
• If you want to produce troubleshooting files for the appliance, see Downloading Advanced Troubleshooting
Files, on page 288
• If you want to download advanced troubleshooting files for the appliance, see Downloading Advanced
Troubleshooting Files, on page 288
• If you want to execute Firepower Threat Defense CLI commands from the Firepower Management Center
web interface, see Using the FTD CLI from the Web Interface, on page 289

Running All Modules for an Appliance

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint/Any

Security Analyst

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; see Viewing Appliance Health Monitors, on page 258.
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.

Firepower Management Center Configuration Guide, Version 6.3

259
 System Monitoring and Troubleshooting
Running a Specific Health Module

Running a Specific Health Module

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint/Any

Security Analyst

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 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 258.
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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint/Any

Security Analyst

You can graph the results over a period of time of a particular health test for a specific appliance.

Procedure

Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 258.
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.

Firepower Management Center Configuration Guide, Version 6.3

260
 System Monitoring and Troubleshooting
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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint/Any

Security Analyst

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.
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.

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint/Any

Security Analyst

Firepower Management Center Configuration Guide, Version 6.3

261
 System Monitoring and Troubleshooting
Viewing the Health Events Table

Procedure

Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 258.
Step 2 In the Module Status Summary graph, click the color for the event status category you want to view.
The Alert Detail list toggles the display to show or hide events.

Step 3 In the Alert Detail row for the alert for which you want to view a list of events, click Events.
The Health Events page appears, containing results for a query with the name of the appliance and the name
of the specified health alert module as constraints. If no events appear, you may need to adjust the time range.
Step 4 If you want to view all health events for the specified appliance, expand Search Constraints, and click the
Module Name constraint to remove it.

Viewing the Health Events Table

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint/Any

Security Analyst

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

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.

Firepower Management Center Configuration Guide, Version 6.3

262
 System Monitoring and Troubleshooting
Hardware Alert Details for 7000 and 8000 Series Devices

• 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 the status icon in the Status column for an
event with that status.

Hardware Alert Details for 7000 and 8000 Series Devices

Note The 8350 hardware platform has six fans, which display as FAN2 through FAN7. This is expected behavior.
If you receive a hardware alert related to FAN1 or fan numbering in general on the 8350 platform, you can
disregard the alert.

Table 26: Conditions Monitored for 7000 and 8000 SeriesDevices

Condition Monitored Causes of Yellow or Red Error Conditions

Device high availability status If 7000 or 8000 Series devices in a high-availability

pair are no longer communicating with each other
(due, for example, to a cabling problem), the
Hardware Alarms module changes to red.

ftwo daemon status If the ftwo daemon goes down, health status for the
Hardware Alarms module changes to red and message
details include a reference to the daemon.

NFE cards detected Indicates the number of NFE cards detected on the
system. If this value does not match the appliance’s
expected NFE count, the Hardware Alarms module
changes to red.

NFE hardware status If one or more NFE cards are not communicating, the
Hardware Alarms module changes to red and the
applicable card appears in the message details.

NFE heartbeat If the system detects no NFE heartbeat, the Hardware

Alarms module changes to red and message details
include a reference to the relevant card(s).

NFE internal link status If the link between the NMSB and NFE card(s) goes
down, the Hardware Alarms module changes to red
and message details include a reference to the relevant
ports.

Firepower Management Center Configuration Guide, Version 6.3

263
 System Monitoring and Troubleshooting
Hardware Alert Details for 7000 and 8000 Series Devices

Condition Monitored Causes of Yellow or Red Error Conditions

NFE Message daemon If the NFE Message daemon goes down, health status
for the Hardware Alarms module changes to red and
the message details include a reference to the daemon
(and, if applicable, the NFE card number).

NFE temperature If NFE temperature exceeds 97 degrees Celsius, health

status for the Hardware Alarms module changes to
yellow and message details include a reference to the
NFE temperature (and, if applicable, the NFE card
number).
If NFE temperature exceeds 102 degrees Celsius,
health status for the Hardware Alarms module changes
to red and message details include a reference to the
NFE temperature. (and, if applicable, the NFE card
number).

NFE temperature status Indicates the current temperature status of the given
NFE card. The Hardware Alarms module indicates
green for OK, yellow for Warning, and red for Critical
(and, if applicable, the NFE card number).

NFE TCAM daemon If the NFE TCAM daemon goes down, health status for
the Hardware Alarms module changes to red and
message details include a reference to the daemon
(and, if applicable, the NFE card number).

nfm_ipfragd (host frag) daemon If the nfm_ipfragd daemon goes down, health status
for the Hardware Alarms module changes to red and
message details include a reference to the daemon
(and, if applicable, the NFE card number).

NFE Platform daemon If the NFE Platform daemon goes down, health status
for the Hardware Alarms module changes to red and
message details include a reference to the daemon
(and, if applicable, the NFE card number).

NMSB communications If the Media assembly is not present or not

communicating, health status for the Hardware Alarms
module changes to red and message details include a
reference to the NFE temperature (and, if applicable,
the NFE card number).

psls daemon status If the psls daemon goes down, health status for the
Hardware Alarms module changes to red and message
details include a reference to the daemon.

Rulesd (host rules) daemon If the Rulesd daemon goes down, health status for the
Hardware Alarms module changes to yellow and
message details include a reference to the daemon
(and, if applicable, the NFE card number).

Firepower Management Center Configuration Guide, Version 6.3

264
 System Monitoring and Troubleshooting
The Health Events Table

Condition Monitored Causes of Yellow or Red Error Conditions

scmd daemon status If the scmd daemon goes down, health status for the
Hardware Alarms module changes to red and message
details include a reference to the daemon.

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 27: 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 (%).

Firepower Management Center Configuration Guide, Version 6.3

265
 System Monitoring and Troubleshooting
History for Health Monitoring

Field Description

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.

Device The appliance where the health event was reported.

History for Health Monitoring

Feature Version Details

New health module: Threat Data Updates 6.3 A new module, Threat Data Updates on
on Devices Devices, was added.
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.
New screens: New health policy on
System > Health > Policy
Modified screens: New monitor results on
System > Health > Monitor
Supported platforms: Firepower
Management Center and managed devices
running version 6.3 and higher.

Health monitoring — Feature introduced before Version 6.0.

New screens: Menu options under
System > Health
Supported platforms: Firepower
Management Center and managed devices.

Firepower Management Center Configuration Guide, Version 6.3

266
 CHAPTER 13
Monitoring the System
The following topics describe how to monitor the Firepower System:
• System Statistics, on page 267
• System Statistics Availability by Appliance, on page 267
• The Host Statistics Section, on page 268
• The Disk Usage Section, on page 268
• The Processes Section, on page 268
• The SFDataCorrelator Process Statistics Section, on page 275
• The Intrusion Event Information Section, on page 275
• Viewing System Statistics, on page 276

System Statistics
The Statistics page in the Firepower System web interface lists the current status of general appliance statistics,
including disk usage and system processes, Data Correlator statistics, and intrusion event information.
You view system statistics on both the Firepower Management Center and 7000 & 8000 Series devices.

System Statistics Availability by Appliance

System statistics are available in the web interface as follows:

Type of Statistics Statistics Page Section FMC 7000 & 8000 Series
Devices

host statistics The Host Statistics Section, on page yes yes

268

system status and disk The Disk Usage Section, on page yes yes
space usage 268

system process status The Processes Section, on page 268 yes yes

Data Correlator The SFDataCorrelator Process yes no

statistics Statistics Section, on page 275

Firepower Management Center Configuration Guide, Version 6.3

267
 System Monitoring and Troubleshooting
The Host Statistics Section

Type of Statistics Statistics Page Section FMC 7000 & 8000 Series
Devices

intrusion event The Intrusion Event Information yes no

statistics Section, on page 275

The Host Statistics Section

The following table describes the host statistics listed on the Statistics page.

Table 28: 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.

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 On the Firepower Management Center, you can also use the 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.

Firepower Management Center Configuration Guide, Version 6.3

268
 System Monitoring and Troubleshooting
Process Status Fields

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
• 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 29: 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

Firepower Management Center Configuration Guide, Version 6.3

269
 System Monitoring and Troubleshooting
System Daemons

Column Description

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)

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 270
Executables and System Utilities, on page 272

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.

Firepower Management Center Configuration Guide, Version 6.3

270
System Monitoring and Troubleshooting
System Daemons

Note The table below is not an exhaustive list of all processes that may run on an appliance.

Table 30: System Daemons

Daemon Description

crond Manages the execution of scheduled commands (cron

jobs)

dhclient Manages dynamic host IP addressing

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

Firepower Management Center Configuration Guide, Version 6.3

271
 System Monitoring and Troubleshooting
Executables and System Utilities

Daemon Description

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

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

Executables and System Utilities

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 31: 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

Firepower Management Center Configuration Guide, Version 6.3

272
System Monitoring and Troubleshooting
Executables and System Utilities

Executable Description

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

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

Firepower Management Center Configuration Guide, Version 6.3

273
 System Monitoring and Troubleshooting
Executables and System Utilities

Executable Description

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

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

Firepower Management Center Configuration Guide, Version 6.3

274
 System Monitoring and Troubleshooting
The SFDataCorrelator Process Statistics Section

Related Topics
Configuring the Access List for Your System, on page 1030

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
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 32: Data Correlator Process Statistics

Category Description

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.

Firepower Management Center Configuration Guide, Version 6.3

275
 System Monitoring and Troubleshooting
Viewing System Statistics

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 33: Intrusion Event Information

Statistic Description

Last Alert Was The date and time that the last event occurred

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Global only Admin/Maint

Threat (for intrusion Protection (for

event data) intrusion event data)

On the Firepower Management Center, the web interface displays statistics for that appliance and any devices
it manages. On 7000 and 8000 Series devices, the system displays statistics for that device only.

Procedure

Step 1 Choose System > Monitoring > Statistics.

Step 2 On the Firepower Management Center: Choose a device from the Select Device(s) list, and click Select
Devices.
Step 3 View available statistics; see System Statistics Availability by Appliance, on page 267.
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

Firepower Management Center Configuration Guide, Version 6.3

276
System Monitoring and Troubleshooting
Viewing System Statistics

• 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 Optionally, click the arrow next to Processes to view the information described in Process Status Fields, on
page 269.

Firepower Management Center Configuration Guide, Version 6.3

277
 System Monitoring and Troubleshooting
Viewing System Statistics

Firepower Management Center Configuration Guide, Version 6.3

278
 CHAPTER 14
Troubleshooting the System
The following topics describe ways to diagnose problems you may encounter with the Firepower System:
• First Steps for Troubleshooting, on page 279
• System Messages, on page 279
• Managing System Messages, on page 282
• Health Monitor Reports for Troubleshooting, on page 286
• General Troubleshooting, on page 289
• Advanced Troubleshooting for the Firepower Threat Defense Device, on page 289
• Feature-Specific Troubleshooting, on page 293

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 286 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 279
• 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 Firepower Management Center Deployments, on page 12.

System Messages
When you need to track down problems occurring in the Firepower System, the Message Center is the place
to start your investigation. This feature allows you to view the messages that the Firepower System continually
generates about system activities and status.
To open the Message Center, click on the System Status icon, located to the immediate right of the Deploy
button 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.

Firepower Management Center Configuration Guide, Version 6.3

279
 System Monitoring and Troubleshooting
Message Types

• — 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 their
dismissal icons ( ). 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 318. 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 239. The
Firepower System reports the following health status values on this tab:

• Warning ( ) — Indicates that warning limits have been exceeded for a health module on an appliance
and the problem has not been corrected. The Health Monitoring page indicates these conditions
with a yellow triangle icon ( ). 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

Firepower Management Center Configuration Guide, Version 6.3

280
 System Monitoring and Troubleshooting
Message Management

with a 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 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 (spinning ) — 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 ( ) — Indicates a task that was interrupted due to a system update. Stopped tasks cannot
be resumed.

New messages appear in this tab as new tasks are started. As tasks complete (status success, failure, or
stopped), this tab continues to display messages with final status indicated until you remove them. Cisco
recommends you remove messages to reduce clutter in the Tasks tab as well as the message database.

Message Management
From the Message Center you can:
• Configure pop-up notification behavior (choosing whether to display them).
• Display additional task status messages from the system database (if any are available that have not been
removed).
• Remove individual task status messages. (This affects all users who can view the removed messages.)
• Remove task status messages in bulk. (This affects all users who can view the removed messages.)

Firepower Management Center Configuration Guide, Version 6.3

281
 System Monitoring and Troubleshooting
Managing System 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.

Managing System Messages

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Deployment:

Admin/custom user
role with Deploy
Configuration to
Devices permission
Health:
Admin/custom user
role with Health
permission
Tasks initiated by
others:
Admin/custom user
role with View
Other Users' Tasks
permission
Tasks you have
initiated: Any

Procedure

Step 1 Click on the System Status icon to display the Message Center.
Step 2 You have the following choices:
• Click on the Deployments tab to view messages related to configuration deployments. See Viewing
Deployment Messages, on page 283.
• Click on the Health tab to view messages related to the health of your Firepower Management Center
and the devices registered to it. See Viewing Health Messages, on page 284.
• Click on the Tasks tab to view or manage messages related to long-running tasks. See Viewing Task
Messages, on page 285 or Managing Task Messages, on page 285.
• Click on the cog icon ( ) in the upper right corner of the Message Center to configure pop-up notification
behavior. See Configuring Notification Behavior, on page 286.

Firepower Management Center Configuration Guide, Version 6.3

282
 System Monitoring and Troubleshooting
Viewing Deployment Messages

Viewing Deployment Messages

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/user role

with Deploy
Configuration to
Devices permission

Procedure

Step 1 Click on the System Status icon to display the Message Center.
Step 2 Click on the Deployments tab.
Step 3 You have the following choices:
• Click on total to view all current deployment statuses.
• Click on a status value to view only messages with that deployment status.
• Hover your cursor over the time elapsed indicator for a message (e.g., 1m 5s) to view the elapsed time,
and start and stop times for the deployment.

Step 4 Click Show 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 the
download icon in the Transcript column for the device.
The transcript includes the following sections:
• Snort Apply—If there are any failures or responses from Snort-related policies, messages appear
in this section. Normally, the section is empty.
• CLI Apply—This section covers features that are configured using commands sent to the Lina
process.
• Infrastructure Messages—This section shows the status of different deployment modules.

In the CLI Apply section, the deployment transcript includes commands sent to the device, and any
responses returned from the device. These response can be informative messages or error messages. For
failed deployments, look for messages that indicate errors with the commands. Examining these errors
can be particularly helpful if you are using FlexConfig policies to configure customized features. These
errors can help you correct the script in the FlexConfig object that is trying to configure the commands.
Note There is no distinction made in the transcript between commands sent for managed features and
those generated from FlexConfig policies.

Firepower Management Center Configuration Guide, Version 6.3

283
 System Monitoring and Troubleshooting
Viewing Health Messages

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 308

Viewing Health Messages

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/user role

with Health
permission

Procedure

Step 1 Click on the System Status icon to display the Message Center.
Step 2 Click on the Health tab.
Step 3 You have the following choices:
• Click on 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 (e.g., 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 on the message.
• To view complete health status on the Health Monitoring page, click on Health Monitor at the bottom
of the tab.

Related Topics
About Health Monitoring, on page 239

Firepower Management Center Configuration Guide, Version 6.3

284
 System Monitoring and Troubleshooting
Viewing Task Messages

Viewing Task Messages

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Tasks initiated by

others:
Admin/custom user
role with View
Other Users' Tasks
permission
Tasks you have
initiated: Any

Procedure

Step 1 Click on the System Status icon to display the Message Center.
Step 2 Click on the Tasks tab.
Step 3 You have the following choices:
• Click on total to view all current task statuses.
• Click on 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 on any link within a message to view more information about the task.
• If more task status messages are available for display, click on Fetch more messages at the bottom of
the message list to retrieve them.

Managing Task Messages

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Tasks initiated by

others:
Admin/custom user
role with View
Other Users' Tasks
permission
Tasks you have
initiated: Any

Firepower Management Center Configuration Guide, Version 6.3

285
 System Monitoring and Troubleshooting
Configuring Notification Behavior

Procedure

Step 1 Click on the System Status icon to display the Message Center.
Step 2 Click on the Tasks tab.
Step 3 You have the following choices:
• 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 the remove
icon ( ) 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.

Configuring Notification Behavior

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Any

Note This setting affects all pop-up notifications and persists between login sessions.

Procedure

Step 1 Click on the System Status icon to display the Message Center.
Step 2 Click on the cog icon ( ) 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 on the cog icon ( ) again to hide the slider.
Step 5 Click on the System Status icon again to close the Message Center.

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

Firepower Management Center Configuration Guide, Version 6.3

286
 System Monitoring and Troubleshooting
Producing Troubleshooting Files for Specific System Functions

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.

Table 34: 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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint/Any

Security Analyst

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.

Firepower Management Center Configuration Guide, Version 6.3

287
 System Monitoring and Troubleshooting
Downloading Advanced Troubleshooting Files

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 312 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 Firepower 7010, 7020, and 7030; ASA 5508-X, 5516-X, 5515-X, and 5525-X;
NGIPSv.

Procedure

Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 258.
Step 2 Click Generate Troubleshooting Files.
Step 3 Choose All Data to generate all possible troubleshooting date, or check individual boxes as described in
Viewing Task Messages, on page 285.
Step 4 Click OK.
Step 5 View task messages in the Message Center; see Viewing Task Messages, on page 285.
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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint/Any

Security Analyst

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.

Procedure

Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 258.
Step 2 Click Advanced Troubleshooting.
Step 3 On the File Download tab, enter the file name supplied by Support.
Step 4 Click Download.

Firepower Management Center Configuration Guide, Version 6.3

288
 System Monitoring and Troubleshooting
General Troubleshooting

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
A non-disgraceful shutdown or a reboot in the system is caused due to an internal power failure (hardware
failure, power surge, and so on) or an external power failure (unplugged cord). These can eventually result
in data corruption.

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 IDS. 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 288

Using the FTD CLI from the Web Interface

Smart License Classic License Supported Devices Supported Domains Access

Any Any FTD Any Admin/Maint/Any

Security Analyst

You can execute selected FTD command line interface (CLI) commands from the Firepower Management
Center web interface. These commands are ping, packet-tracer, traceroute, and show (except for the show
subcommands history and 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.

Firepower Management Center Configuration Guide, Version 6.3

289
 System Monitoring and Troubleshooting
Packet Tracer Overview

Procedure

Step 1 View the health monitor for the appliance; see Viewing Appliance Health Monitors, on page 258.
Step 2 Click Advanced Troubleshooting.
Step 3 Click the Threat Defense CLI tab.
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.

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 liming 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 logs the tracing data on per packet basis when
the Next-Generation Firewall (NGFW) processes packet per-session or per-packet basis.

Use the Packet Tracer

Smart License Classic License Supported Devices Supported Domains Access

Any n/a Firepower Threat Any Admin/Maint

Defense

Procedure

Step 1 On the Firepower Management Center, choose Devices > Device Management.
Step 2 Select a device.
Step 3 Click the troubleshooting icon.
The Health Monitor page appears.
Step 4 Click Advanced Troubleshooting.
Step 5 Click the Packet Tracer tab.
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.

Firepower Management Center Configuration Guide, Version 6.3

290
 System Monitoring and Troubleshooting
Packet Capture Overview

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.

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.
In 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.

Packet Capture Overview

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
DROP/ALLOW/Would DROP.
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 capture_name.pcap .
The file-size option is used when you need to capture packets with the size limit more than 32 MB.
For information, see Command Reference for Firepower Threat Defense.

Firepower Management Center Configuration Guide, Version 6.3

291
 System Monitoring and Troubleshooting
Use the Capture Trace

Use the Capture Trace

Smart License Classic License Supported Devices Supported Domains Access

Any n/a Firepower Threat Any Admin/Maint

Defense

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.

Procedure

Step 1 On the Firepower Management Center, choose Devices > Device Management.
Step 2 Select a device.
Step 3 Click the troubleshooting icon.
The Health Monitor page appears.
Step 4 Click Advanced Troubleshooting.
Step 5 Select the Capture w/Trace tab.
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.

Firepower Management Center Configuration Guide, Version 6.3

292
 System Monitoring and Troubleshooting
Feature-Specific Troubleshooting

Feature-Specific Troubleshooting
See the following table for feature-specific troubleshooting tips and techniques.

Table 35: Feature-Specific Troubleshooting Topics

Feature Relevant Troubleshooting Information

LDAP external authentication Troubleshooting LDAP Authentication Connections, on page 73

7000 and 8000 Series device high-availability state sharing Device High Availability State Sharing Statistics for
Troubleshooting, on page 561

User rule conditions Troubleshoot User Control, on page 345

User identity sources Troubleshoot the User Agent Identity Source, on page 2136
Troubleshoot the ISE/ISE-PIC Identity Source, on page 2109
Troubleshoot the TS Agent Identity Source, on page 2132
Troubleshoot the Captive Portal Identity Source, on page 2124
Troubleshoot the Remote Access VPN Identity Source, on page
2128

URL filtering Troubleshoot URL Filtering, on page 1399

Realms and user data downloads Troubleshoot Realms and User Downloads, on page 2100

Network discovery Troubleshooting Your Network Discovery Strategy, on page 2169

Custom Security Group Tag (SGT) rule conditions Troubleshooting Custom SGT Conditions, on page 348

SSL rules Troubleshoot TLS/SSL Rules, on page 1535

Cisco Threat Intelligence Director (TID) Troubleshoot Cisco Threat Intelligence Director (TID), on page
1628

Firepower Threat Defense syslog Configure Syslog, on page 1113

Intrusion performance statistics Intrusion Performance Statistic Logging Configuration, on page

1853

7000 and 8000 Series, NGIPSv, and ASA with FirePOWER generate-troubleshoot, on page 2742
Services Command Line Interface (CLI)

Integration with Cisco Security Packet Analyzer Troubleshoot Packet Analyzer Queries, on page 2353

Firepower Management Center Configuration Guide, Version 6.3

293
 System Monitoring and Troubleshooting
Feature-Specific Troubleshooting

Firepower Management Center Configuration Guide, Version 6.3

294
PA R T IV
Deployment Management
• Domain Management, on page 297
• Policy Management, on page 305
• Rule Management: Common Characteristics, on page 321
• Reusable Objects, on page 361
• Firepower Threat Defense Certificate-Based Authentication, on page 463
 CHAPTER 15
Domain Management
The following topics describe how to manage multitenancy using domains:
• Introduction to Multitenancy Using Domains, on page 297
• Managing Domains, on page 300
• Creating New Domains, on page 301
• Moving Data Between Domains, on page 302
• Moving Devices Between Domains, on page 303

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 50 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.

Tip Each task topic in this guide has a Supported Domains value that indicates the domain levels where you can
perform the task.

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.

Firepower Management Center Configuration Guide, Version 6.3

297
 Deployment Management
Domains Terminology

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.

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 can log into the Global domain to manage all customers’ deployments.
• 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 can log into a second-level subdomain to manage the customer’s entire
deployment.
• 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.

Domains Terminology
This documentation uses the following terms when describing domains and multidomain deployments:
Global Domain
In a multidomain deployment, the top-level domain. If you do not configure multitenancy, all devices,
configurations, and events belong to the Global domain. Administrators in the Global domain can manage
the entire Firepower System deployment.
Subdomain
A second or third-level domain.
Second-level domain
A child of the Global domain. Second-level domains can be leaf domains, or they can have subdomains.
Third-level domain
A child of a second-level domain. Third-level domains are always leaf domains.

Firepower Management Center Configuration Guide, Version 6.3

298
 Deployment Management
Domain Properties

Leaf domain
A domain with no subdomains. Each device must belong to a leaf domain.
Descendant domain
A domain descending from the current domain in the hierarchy.
Child domain
A domain’s direct descendant.
Ancestor domain
A domain from which the current domain descends.
Parent domain
A domain’s direct ancestor.
Sibling domain
A domain with the same parent.
Current domain
The domain you are logged into now. The system displays the name of the current domain before your
user name at the top right of the web interface. Unless your user role is restricted, you can edit
configurations in the current domain.

Domain Properties
To modify a domain's properties, you must have Administrator access in that domain's parent domain.
Name and Description
Each domain must have a unique name within its hierarchy. A description is optional.
Parent Domain
Second- and third-level domains have a parent domain. You cannot change a domain's parent after you
create the domain.
Devices
Only leaf domains may contain devices. In other words, a domain may contain subdomains or devices,
but not both. You cannot save a deployment where a non-leaf domain directly controls a device.
In the domain editor, the web interface displays available and selected devices according to their current
place in your domain hierarchy.
Host Limit
The number of hosts a Firepower Management Center can monitor, and therefore store in network maps,
depends on its model. In a multidomain deployment, leaf domains share the available pool of monitored
hosts, but have separate network maps.
To ensure that each leaf domain can populate its network map, you can set host limits at each subdomain
level. If you set a domain's host limit to 0, the domain shares in the general pool.
Setting the host limit has a different effect at each domain level:

Firepower Management Center Configuration Guide, Version 6.3

299
 Deployment Management
Managing Domains

• 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 2023
Network Discovery Data Storage Settings, on page 2165

Managing Domains
Smart License Classic License Supported Device Supported Domains Access

Any Any Any Any Admin

To modify a domain's properties, you must have Administrator access in that domain's parent domain.

Procedure

Step 1 Choose System > Domains.

Step 2 Manage your domains:
• Add — Click Add Domain, or click the Add Subdomain icon next to the parent domain; see Creating
New Domains, on page 301.
• Edit — Click the edit icon ( ) next to the domain you want to modify; see Domain Properties, on page
299.
• Delete — Click the delete icon ( ) 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:

Firepower Management Center Configuration Guide, Version 6.3

300
 Deployment Management
Creating New Domains

• If you changed a leaf domain to a parent domain, move or delete the old network map; see Moving Data
Between Domains, on page 302.
• If you moved devices between domains and must assign new policies and security zones or interface
groups, see Moving Devices Between Domains, on page 303.

What to do next
• Configure user roles and policies (access control, network discovery, and so on) for any new domains.
Update device properties as needed.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Creating New Domains

Smart License Classic License Supported Device Supported Domains Access

Any Any Any Global & Admin

second-level

You can create up to 50 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 the Add Subdomain icon next to the parent domain.
Step 3 Enter a Name and Description.
Step 4 Choose a Parent Domain.
Step 5 On the Devices tab, 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 the Advanced tab to limit the number of hosts the new domain may monitor; see Domain
Properties, on page 299.
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.
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 302.

Firepower Management Center Configuration Guide, Version 6.3

301
 Deployment Management
Moving Data Between Domains

• If you moved devices between domains and must assign new policies and security zones or interface
groups, see Moving Devices Between Domains, on page 303.

What to do next
• Configure user roles and policies (access control, network discovery, and so on) for any new domains.
Update device properties as needed.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Moving Data Between Domains

Smart License Classic License Supported Device Supported Domains Access
Any Any Any Any Admin

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 300.

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
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

302
 Deployment Management
Moving Devices Between Domains

Moving Devices Between Domains

Smart License Classic License Supported Device Supported Domains Access

Any Any Any Global & Admin

second-level

Moving a device between domains can affect the configurations and policies applied to the device. The system
automatically keeps and updates what it can, and deletes what it cannot.
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 300.

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.

Firepower Management Center Configuration Guide, Version 6.3

303
 Deployment Management
Moving Devices Between Domains

Step 5 After you configure all affected devices, click Save to save policy and zone assignments.
Step 6 Click Save to implement the domain configuration.

What to do next
• Update other configurations on the moved device that were affected by the move.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

304
 CHAPTER 16
Policy Management
The following topics describe how to manage various policies on the Firepower Management Center:
• Policy Deployment, on page 305
• Policy Comparison, on page 316
• Policy Reports, on page 317
• Out-of-Date Policies, on page 318
• Performance Considerations for Limited Deployments, on page 319

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

Firepower Management Center Configuration Guide, Version 6.3

305
 Deployment Management
Guidelines for Deploying Configuration Changes

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. For example, it can
take up to five minutes to deploy to a Firepower 7010, 7020, or 7030 device.

Do not exceed the capability of your devices. If you exceed the maximum number 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 Rule Performance Guidelines, on page 352.

Interruptions to Traffic Flow and Inspection During Deploy

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 312 and Configurations that Restart the
Snort Process When Deployed or Activated, on page 313.
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 307 for more information.

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 311

Firepower Management Center Configuration Guide, Version 6.3

306
 Deployment Management
Restart Warnings for Firepower Threat Defense Devices

Restart Warnings for Firepower Threat Defense Devices

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Network

Admin/Security
Approver

When you deploy, the Inspect Interruption column in the deploy dialog 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 highlights in red along with a restart icon ( ) any specific configuration type that would restart the
Snort process. When you hover your mouse over these configurations, a message informs you that deploying
the configuration may interrupt traffic.
The following table summarizes how the deploy dialog displays inspection interruption warnings.

Table 36: Inspection Interruption Indicators in the Deploy Dialog

Type Inspect Interruption Description

FTD Yes At least one configuration would interrupt

inspection on the device if deployed, and might
interrupt traffic depending on how the device
handles traffic. You can expand the device
configuration listing for more information.

No Deployed configurations will not interrupt traffic

on the device.

Undetermined The system cannot determine if a deployed

configuration may interrupt traffic on the device,
and displays a device warning icon ( ) next to
the device.
Undetermined status is displayed before the first
deployment after a software upgrade, or in some
cases during a Support call.

The system cannot determine the status due to an

Error
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.

Firepower Management Center Configuration Guide, Version 6.3

307
 Deployment Management
Deploy Configuration Changes

Type Inspect Interruption Description

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 313.

Deploy Configuration Changes

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Network

Admin/Security
Approver

After you change configurations, deploy to the affected devices. 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.

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 312 and Configurations that Restart the
Snort Process When Deployed or Activated, on page 313.

Before you begin

• Review the guidelines described in Guidelines for Deploying Configuration Changes, on page 306.
• 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 532.

Procedure

Step 1 On the Firepower Management Center menu bar, click Deploy.

The Deploy Policies dialog lists devices with out-of-date configurations. The Version at the top of the dialog
specifies when you last made configuration changes.

Step 2 Identify and choose the devices where you want to deploy configuration changes.
• Sort—Sort the device list by clicking a column heading.

Firepower Management Center Configuration Guide, Version 6.3

308
Deployment Management
Deploy Configuration Changes

See Restart Warnings for Firepower Threat Defense Devices, on page 307 for information on columns
that help you identify configurations that interrupt traffic inspection and might interrupt traffic when
deployed to Firepower Threat Defense devices.

See Configurations that Restart the Snort Process When Deployed or Activated, on page 313 for information
on configurations that interrupt traffic inspection and might interrupt traffic when deployed to all devices.

• Expand—Click the plus icon ( ) to expand a device listing to view the configuration changes to be
deployed. The system marks out-of-date policies with an index ( ) icon.
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 highlights in
red the configurations causing the interruption.
• Filter—Filter the device list. Click the arrow in the right corner of any column heading:
• Inspect Interruption column—From the Filters drop-down list check the desired filter options.
You can choose more than one option.
For more information on restart warnings, see Restart Warnings for Firepower Threat Defense
Devices, on page 307.
• All other columns—Enter text in the Filters text box, and press Enter.

Check or uncheck Filters to activate or deactivate the filter.

• Modify—Click the cog icon ( ) in the upper-right corner and, from the Columns drop-down list, check
or uncheck columns to display.
• Arrange—Place the mouse on a column heading to drag and drop the column in your preferred order.

Step 3 Click Deploy.

Step 4 If the system identifies errors or warnings in the changes to be deployed, you have the following choices:
• Proceed—Continue deploying without resolving warning conditions.You cannot proceed if the system
identifies errors.
• Cancel—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 283.
• If deploy fails, see Guidelines for Deploying Configuration Changes, on page 306.

Related Topics
Snort® Restart Scenarios, on page 311

Firepower Management Center Configuration Guide, Version 6.3

309
 Deployment Management
Redeploy Existing Configurations to a Device

Redeploy Existing Configurations to a Device

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Leaf only Admin/Network

Admin/Security
Approver

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.

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 312 and Configurations that Restart the
Snort Process When Deployed or Activated, on page 313.

Before you begin

Review the guidelines described in Guidelines for Deploying Configuration Changes, on page 306.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Click the edit icon ( ) next to the device where you want to force deployment.
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Device tab.

Step 4 Click the edit icon ( ) next to the General section heading.
Step 5 Click the Force Deploy arrow ( ).
Step 6 Click Deploy.
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.

What to do next
• (Optional) Monitor deployment status; see Viewing Deployment Messages, on page 283.
• If deploy fails, see Guidelines for Deploying Configuration Changes, on page 306.

Related Topics
Snort® Restart Scenarios, on page 311

Firepower Management Center Configuration Guide, Version 6.3

310
 Deployment Management
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
312 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 37: 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 313

Modifying a configuration that immediately restarts Changes that Immediately Restart the Snort Process,
the Snort process. on page 315

Traffic-activation of the currently deployed Automatic Configuring Automatic Application Bypass, on page
Application Bypass (AAB) configuration. 509

Related Topics
Access Control Policy Advanced Settings, on page 1362
Configurations that Restart the Snort Process When Deployed or Activated, on page 313

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.

Firepower Management Center Configuration Guide, Version 6.3

311
 Deployment Management
Snort® Restart Traffic Behavior

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 312 and Configurations that Restart the
Snort Process When Deployed or Activated, on page 313.

Snort® Restart Traffic Behavior

The following tables explain how different devices handle traffic when the Snort process restarts.

Table 38: 7000 and 8000 Series, NGIPSv Restart Traffic Effects

Interface Configuration Restart Traffic Behavior

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

routed, switched dropped

(7000 and 8000 Series only)

Table 39: FTD Restart Traffic Effects

Interface Configuration Restart Traffic Behavior

inline, Snort Fail Open: Down: disabled dropped

inline, Snort Fail Open: Down: enabled passed without inspection

Firepower Management Center Configuration Guide, Version 6.3

312
 Deployment Management
Configurations that Restart the Snort Process When Deployed or Activated

Interface Configuration Restart Traffic Behavior

routed, transparent (including EtherChannel, existing TCP/UDP flows: passed without inspection
redundant, subinterface)
new flows and existing non-TCP/UDP flows: dropped
CLI command: configure snort
preserve-connection enable (default); an FTD
managed by a 6.3.x FMC must be running version
6.3.x, 6.2.3, 6.2.0.2, or a subsequent 6.2.0.x patch.
For more information, see Command Reference for
Firepower Threat Defense.

routed, transparent (including EtherChannel, dropped

redundant, subinterface)
CLI command: configure snort
preserve-connection disable; or, the FTD version
(6.2.1, 6.2.2, 6.2.2.x, or a version earlier than 6.2.0.2)
does not support this command.

inline, tap mode egress packet immediately, copy bypasses Snort

passive uninterrupted, not inspected

Table 40: ASA FirePOWER Restart Traffic Effects

Interface Configuration Restart Traffic Behavior

routed or transparent with fail-open passed without inspection

routed or transparent with fail-close dropped

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 540) or the Snort Fail Open Busy option (see Configure an Inline
Set, on page 681). 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.

Firepower Management Center Configuration Guide, Version 6.3

313
 Deployment Management
Configurations that Restart the Snort Process When Deployed or Activated

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.

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
• Routing—Add a routed interface pair or virtual router to a 7000 or 8000 Series device.
• VPN—Add or remove a VPN on a 7000 or 8000 Series device.

Firepower Management Center Configuration Guide, Version 6.3

314
 Deployment Management
Changes that Immediately Restart the Snort Process

Caution The system does not warn you that the Snort process restarts when you add or
remove a VPN on a 7000 or 8000 Series device.

• MTU—Change the highest MTU value among all non-management interfaces on a device.
• Classic device high availability—Change a high-availability state sharing option. The system does not
warn you that the Snort process restarts on the primary and secondary devices.
• Automatic Application Bypass (AAB)—The currently deployed AAB configuration activates when a
malfunction of the Snort process or a device misconfiguration causes a single packet to use an excessive
amount of processing time. The result is a partial restart of the Snort process to alleviate extremely high
latency or prevent a complete traffic stall. This partial restart causes a few packets to pass without
inspection, or drop, depending on how the device handles traffic.

Updates
• System update—Deploy configurations the first time after a software update that includes a new version
of the Snort binary or data acquisition library (DAQ).
• VDB—Deploy configurations the first time after installing a vulnerability database (VDB) update that
includes changes applicable to managed devices. For these, a message warns you when you select the
Firepower Management Center to begin installing. The deploy dialog provides additional warnings for
Firepower Threat Defense devices when VDB changes are pending. VDB updates that apply only to the
Firepower Management Center do not cause restarts, and you cannot deploy them.

Related Topics
Deploy Configuration Changes, on page 308
Snort® Restart Scenarios, on page 311

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,
on page 312 for more information.
• Take any of the following actions involving applications or application detectors:
• Activate or deactivate a system or custom application detector.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

315
 Deployment Management
Policy Comparison

• Restart the Snort process in the 7000 or 8000 Series user interface (System > Configuration >
Process)—The system prompts you for confirmation 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
Smart License Classic License Supported Devices Supported Domains Access
feature dependent feature dependent Any feature dependent feature dependent

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

Firepower Management Center Configuration Guide, Version 6.3

316
 Deployment Management
Policy Reports

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

Smart License Classic License Supported Devices Supported Domains Access
feature dependent feature dependent Any feature dependent feature dependent

Firepower Management Center Configuration Guide, Version 6.3

317
 Deployment Management
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
• NAT for 7000 & 8000 Series devices—Devices > NAT
• 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 the report icon ( ) 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

Firepower Management Center Configuration Guide, Version 6.3

318
 Deployment Management
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 blacklist
or whitelist 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:

Firepower Management Center Configuration Guide, Version 6.3

319
 Deployment Management
Intrusion Prevention Without Discovery

• Do not use the Security Intelligence feature. Remove any populated global whitelist or blacklist 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.
• Make sure that the default intrusion policy for the access control policy 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
The Default Intrusion Policy, on page 1857

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 whitelists and blacklists 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 Whitelist for DNS and Global Blacklist 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.

Firepower Management Center Configuration Guide, Version 6.3

320
 CHAPTER 17
Rule Management: Common Characteristics
The following topics describe how to manage common characteristics of rules in various policies on the
Firepower Management Center:
• Introduction to Rules, on page 321
• Rule Condition Types, on page 323
• Searching for Rules, on page 349
• Filtering Rules by Device, on page 349
• Identify Rules with Issues, on page 350
• Rule and Other Policy Warnings, on page 351
• Rule Performance Guidelines, on page 352
• History for Rule Management: Common Characteristics, on page 360

Introduction to Rules
Rules in various policies exert granular control over network traffic. The system evaluates traffic against rules
in the order that you specify, using a first-match algorithm.
Although these rules may include other configurations that are not consistent across policies, they share many
basic characteristics and configuration mechanics, including:
• Conditions—Rule conditions specify the traffic that each rule handles. You can configure each rule with
multiple conditions. Traffic must match all conditions to match the rule.
• Action—A rule's action determines how the system handles matching traffic. Note that even if a rule
does not have an Action list you can choose from, the rule still has an associated action. For example, a
custom network analysis rule uses a network analysis policy as its "action." As another example, QoS
rules do not have an explicit action because all QoS rules do the same thing: rate limit traffic.
• Position—A rule's position dermines 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 track and log but do
not affect traffic flow, 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

Firepower Management Center Configuration Guide, Version 6.3

321
 Deployment Management
Introduction to Rules

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 1367
• Tunnel and prefilter rules—Tunnel and Prefilter Rule Components, on page 1429
• SSL rules—Creating and Modifying TLS/SSL Rules, on page 1486
• DNS rules—Creating and Editing DNS Rules, on page 1415
• Identity rules—Create an Identity Rule, on page 2140
• Network analysis rules—Configuring Network Analysis Rules, on page 1861
• QoS rules—Configuring QoS Rules, on page 696
• Intelligent Application Bypass (IAB)—Intelligent Application Bypass, on page 1435
• Application filters—Application Filters, on page 375

Rules without Shared Characteristics

Rules whose configurations are not documented in this chapter include:
• Intrusion rules—Tuning Intrusion Policies Using Rules, on page 1675
• File rules—File Rules, on page 1571
• Correlation rules—Configuring Correlation Rules, on page 2193
• NAT rules (Classic)—NAT for 7000 and 8000 Series Devices, on page 1151
• NAT rules (Firepower Threat Defense)—Network Address Translation (NAT) for Firepower Threat
Defense, on page 1169
• 8000 Series fastpath rules—Configuring Fastpath Rules (8000 Series), on page 511

Firepower Management Center Configuration Guide, Version 6.3

322
 Deployment Management
Rule Condition Types

Rule Condition Types

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 325 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 328 Source and destination IP address, Access control rules
and where supported, geographical
Prefilter rules
location or originating client
SSL rules
DNS rules
Identity rules
Network analysis rules
QoS rules

Tunnel Endpoint Conditions, on Source and destination tunnel Tunnel rules

page 330 endpoints for plaintext, passthrough
tunnels

VLAN Conditions, on page 331 VLAN tag Access control rules

Tunnel rules
Prefilter rules
SSL rules
DNS rules
Identity rules
Network analysis rules

Firepower Management Center Configuration Guide, Version 6.3

323
 Deployment Management
Rule Condition Mechanics

Condition Controls Traffic By... Supported Rules/Configurations

Port and ICMP Code Conditions, Source and destination ports, Access control rules
on page 332 protocols, and ICMP codes
Prefilter rules
SSL rules
Identity rules
QoS rules

Encapsulation Conditions, on page Encapsulation protocol Tunnel rules

334 (nonencrypted)

Application Conditions Application or application Access control rules

(Application Control), on page 334 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 342 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)
342 ISE attributes
QoS rules

Custom SGT Conditions, on page Custom Security Group Tag (SGT) Access control rules
346
QoS rules

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.

Firepower Management Center Configuration Guide, Version 6.3

324
 Deployment Management
Interface Conditions

Note 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 that 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.
• 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 the add icon ( ) 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 icon ( ) 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.

Firepower Management Center Configuration Guide, Version 6.3

325
 Deployment Management
Interface Conditions

Depedending 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 379.

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 1431.

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)

Firepower Management Center Configuration Guide, Version 6.3

326
 Deployment Management
Configuring Interface Conditions

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

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 1365.

Procedure

Step 1 In the rule editor, click the tab for interface conditions:
• Interface groups and security zones (tunnel, prefilter, QoS)—Click the Interface Objects tab.
• Security zones (access control, SSL, DNS, identity, network analysis)—Click the Zones tab.
• Tunnel zones (access control)—Click the Zones tab.

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 1431.

Step 3 Click Add to Source or Add to Destination, or drag and drop.

Firepower Management Center Configuration Guide, Version 6.3

327
 Deployment Management
Network Conditions

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 1431.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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 multi-domain 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).

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

Firepower Management Center Configuration Guide, Version 6.3

328
 Deployment Management
Configuring Network Conditions

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

Configuring Network Conditions

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 In the rule editor, click the Networks tab.

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 the Networks sub-tab to choose networks.
• Geolocation—Click the Geolocation sub-tab 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 the Source sub-tab to specify proxy servers.
• Original Client—Click the Original Client sub-tab 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.

Firepower Management Center Configuration Guide, Version 6.3

329
 Deployment Management
Tunnel Endpoint Conditions

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 multi-domain deployment,
using literal IP addresses to constrain this configuration can have unexpected results. Using
override-enabled objects allows descendant domain administrators to tailor Global configurations
to their local environments.

Step 6 Save or continue editing the rule.

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.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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 334) 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 1429.
You can use predefined network objects to build tunnel endpoint conditions, or manually specify individual
IP addresses or address blocks.

Firepower Management Center Configuration Guide, Version 6.3

330
 Deployment Management
Configuring Tunnel Endpoint Conditions

Note The system builds a separate network map for each leaf domain. In a multi-domain 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.

Configuring Tunnel Endpoint Conditions

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Access

Defense Admin/Network
Admin

Procedure

Step 1 In the rule editor, click the Tunnel Endpoints tab.

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.

Step 3 Click Add to Source or Add to Destination, or drag and drop.

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 multi-domain deployment,
using literal IP addresses to constrain this configuration can have unexpected results. Using
override-enabled objects allows descendant domain administrators to tailor Global configurations
to their local environments.

Step 5 Save or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

VLAN Conditions
VLAN rule conditions control VLAN-tagged traffic, including QinQ (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.

Firepower Management Center Configuration Guide, Version 6.3

331
 Deployment Management
Port and ICMP Code Conditions

You can use predefined objects to build VLAN conditions, or manually enter any VLAN tag from 1 to 4094.
Use a hyphen to specify a range of VLAN tags.
You can specify a maximum of 50 VLAN conditions.

Note The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
VLAN tags to constrain this configuration can have unexpected results. Using override-enabled objects allows
descendant domain administrators to tailor Global configurations to their local environments.

Rules with VLAN Conditions

The folllowing rule types support VLAN conditions:
• Access control
• Tunnel and prefilter (uses outermost VLAN tag)
• SSL
• DNS
• 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.

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:

Firepower Management Center Configuration Guide, Version 6.3

332
 Deployment Management
Configuring Port Conditions

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

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 In the rule editor, click the Ports tab.

Step 2 Find and choose the predefined ports you want to add from the Available Ports list.

Firepower Management Center Configuration Guide, Version 6.3

333
 Deployment Management
Encapsulation Conditions

Step 3 Click Add to Source or Add to Destination, or drag and drop.

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.

Step 5 Save or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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 2068.
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).

Firepower Management Center Configuration Guide, Version 6.3

334
Deployment Management
Application Conditions (Application Control)

Note 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 that 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.

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

Firepower Management Center Configuration Guide, Version 6.3

335
 Deployment Management
Configuring Application Conditions and Filters

Configuration Type, Risk, Tags User-Defined Filters Content Restriction

Relevance,
Category

Intelligent yes yes yes no

Application Bypass
(IAB)

Related Topics
Overview: Application Detection, on page 2067

Configuring Application Conditions and Filters

Smart License Classic License Supported Devices Supported Domains Access

Any Control Any Any Admin/Access

Admin/Network
Admin

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.

Before you begin

• Adaptive profiling must be enabled (its default state) as described in Configuring Adaptive Profiles, on
page 2003 for access control rules to perform application control.

Procedure

Step 1 Invoke the rule or configuration editor:

• Access control, SSL, QoS rule condition—In the rule editor, click the Applications tab.
• Identity rule condition—In the rule editor, click the Realms & Settings tab and enable active
authentication; see Create an Identity Rule, on page 2140.
• 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 the Advanced tab, edit
IAB settings, then click Bypassable Applications and Filters.

Step 2 (Optional) For an access control rule, enable content restriction features by clicking the dimmed icons 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 1444.
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.

Firepower Management Center Configuration Guide, Version 6.3

336
Deployment Management
Configuring Application Conditions and Filters

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 the information icon ( ) next to an application to display summary information and internet
search links. The unlock icon ( ) 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.

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
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

337
 Deployment Management
Application Characteristics

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 41: 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.

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.

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.

Speed of Application Identification

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

Firepower Management Center Configuration Guide, Version 6.3

338
Deployment Management
Guidelines and Limitations for Application Control

• 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.
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.
For access control, these passed packets are inspected by the access control policy’s default intrusion policy
(not the default action intrusion policy nor the almost-matched rule’s intrusion policy).
For guidelines about rule ordering for application control, see Recommendations for Application Control, on
page 1369.

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.

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

339
 Deployment Management
Application-Specific Notes and Limitations

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 340.
Related Topics
The Default Intrusion Policy, on page 1857
Special Considerations for Application Detection, on page 2071

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.
• Skype:
See Guidelines and Limitations for Application Control, on page 338
• Zoho:
See Guidelines and Limitations for Application Control, on page 338
• 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.

Troubleshoot Application Control Rules

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.)

Firepower Management Center Configuration Guide, Version 6.3

340
Deployment Management
Troubleshoot Application Control Rules

• 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

Note 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 that rules based on IP address, for example.
Access control rules that use specific conditions (such as networks and IP addresses) should be ordered before
rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect
(OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data
link, and network) should be ordered first in your access control rules. Conditions for layers 5, 6, and 7 (session,
presentation, and application) should be ordered later in your access control rules. For more information about
the OSI model, see this Wikipedia article.

The following table provides an example of how to set up your access control rules:

Type of control Action Zones, Users Applications Ports URLs SGT/ISE Inspection,
Networks, Attributes Logging,
VLAN Comments
Tags

Application Your Any Any Do not set Available Any Use only Any
from less secure choice Ports : with
to more secure (Allow in SSH ISE/ISE-PIC.
network when this
Add to
application uses example)
Selected
a port (for
Destination
example, SSH)
Ports

Application Your Any Any Do not set Selected Do Use only Any
from less secure choice Destination not with
to more secure (Allow in Ports set ISE/ISE-PIC.
network when this Protocol:
application does example) ICMP
not use a port
Type: Any
(for example,
ICMP)

Application Your Your Choose a Choose the Do not set Do Use only Your
access by a user choice choice user group name of the not with choice
group (Block in (Contractors application set ISE/ISE-PIC.
this group in ( Facebook
example) this in this
example) example)

Related Topics
Guidelines for Ordering Rules, on page 353

Firepower Management Center Configuration Guide, Version 6.3

341
 Deployment Management
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 1389.

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 2017.
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 346.

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

Related Topics
The User Agent Identity Source, on page 2135
The ISE/ISE-PIC Identity Source, on page 2105
The Terminal Services (TS) Agent Identity Source, on page 2131

Firepower Management Center Configuration Guide, Version 6.3

342
 Deployment Management
User Control Prerequisites

The Captive Portal Identity Source, on page 2113

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 2017.
If you configure a User Agent, 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
mappings based on groups, due to your Firepower Management Center user limit. As a result, rules with
realm, user, or user group conditions may not match traffic as expected.

Configure Realms
Configure a realm for each AD or LDAP server you want to monitor, including your ISE/ISE-PIC, User
Agent, and TS Agent servers, and perform a user download. For more information, see Create a Realm, on
page 2092.

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 2143.
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.

Firepower Management Center Configuration Guide, Version 6.3

343
 Deployment Management
Configuring User and Realm Conditions

Configuring User and Realm Conditions

Smart License Classic License Supported Devices Supported Domains Access

Any Control Any Any Admin/Access

Admin/Network Admin

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 342.

Procedure

Step 1 In the rule editor, click the Users tab.

Step 2 (Optional) Find and choose the realm you want to use from the Available Realms.
Step 3 (Optional) Further constrain the rule by choosing users and groups from the Available Users list.
Step 4 Click Add to Rule, or drag and drop.
Step 5 Save or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring ISE Attribute Conditions

Smart License Classic License Supported Devices Supported Domains Access

Any Control Any Any Admin/Access

Admin/Network
Admin

Before you begin

• Fulfill the user control prerequisites described in User, Realm, and ISE Attribute Conditions (User
Control), on page 342.

Procedure

Step 1 In the rule editor, click the tab for ISE attribute conditions:
• Access control—Click the SGT/ISE Attributes tab.
• QoS—Click the ISE Attributes tab.

Firepower Management Center Configuration Guide, Version 6.3

344
 Deployment Management
Troubleshoot User Control

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 346.

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)
• 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 4 Click Add to Rule, or drag and drop.
Step 5 (Optional) Constrain the rule with an IP address in the Add a Location IP Address field, then click Add.
The system builds a separate network map for each leaf domain. In a multi-domain deployment, using literal
IP addresses to constrain this configuration can have unexpected results.

Step 6 Save or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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 User Agent Identity Source, on page 2136
• Troubleshoot the ISE/ISE-PIC Identity Source, on page 2109
• Troubleshoot the TS Agent Identity Source, on page 2132
• Troubleshoot the Captive Portal Identity Source, on page 2124
• Troubleshoot Realms and User Downloads, on page 2100

Rules targeting realms, users, or user groups are not matching traffic
If you configure a User Agent, 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.

Firepower Management Center Configuration Guide, Version 6.3

345
 Deployment Management
Custom SGT Conditions

Rules targeting users in secondary groups are not matching traffic as expected
If you configure a rule with a user group condition that includes or excludes users who are members of a
secondary group on your Active Directory server, your server may be limiting the number of users it reports.
By default, Active Directory servers limit the number of users they report from secondary groups. You must
customize this limit so that all of the users in your secondary groups are reported to the Firepower Management
Center and eligible for use in rules with user conditions.

Rules are not matching users when seen for the first time
After the system detects activity from a previously-unseen user, the system retrieves information about them
from the server. Until the system successfully retrieves this information, activity seen by this user is not
handled by matching rules. Instead, the user session is handled by the next rule it matches (or the policy's
default action, if applicable).
For example, this might explain when:
• Users who are members of user groups are not matching rules with user group conditions.
• Users who were reported by a User Agent, TS Agent, or ISE/ISE-PIC device are not matching rules,
when the server used for user data retrieval is an Active Directory server.

Note that this might also cause the system to delay the display of user data in event views and analysis tools.

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, messages similar to the following are displayed in
/var/log/messages:
UserGroup [WARN] User/Group mem usage is above 80 percent

Another message displays the percentage of memory used by users and groups.
If these messages persist, you have the following options:
• Limit the users processed by your access control policy.
• Upgrade your managed device to a model with more memory.

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.

Firepower Management Center Configuration Guide, Version 6.3

346
 Deployment Management
ISE SGT vs Custom SGT Rule Conditions

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

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 342

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 2107

Firepower Management Center Configuration Guide, Version 6.3

347
 Deployment Management
Configuring Custom SGT Conditions

Configuring Custom SGT Conditions

Smart License Classic License Supported Devices Supported Domains Access

Any Control Any Any Admin/Access

Admin/Network
Admin

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 347.

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 376.

Procedure

Step 1 In the rule editor, click the SGT/ISE Attributes tab.

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.

Step 4 Click Add to Rule, or drag and drop.

Step 5 Save or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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 347.

Firepower Management Center Configuration Guide, Version 6.3

348
 Deployment Management
Searching for Rules

Searching for Rules

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

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 the Rules tab.

Step 2 Click the Search Rules prompt, enter a complete or partial search string, then press Enter.
The column for matching values is highlighted for each matching rule. A status message displays the current
match and the total number of matches.
Step 3 Find the rules you are interested in.

To navigate between matching rules, click the next-match ( ) or previous-match ( ) icon.

What to do next

• Before you begin a new search, click the clear icon ( ) to clear the search and any highlighting.

Filtering Rules by Device

Smart License Classic License Supported Devices Supported Domains Access

Any Any feature dependent Any Admin/Access

Admin/Network
Admin

Some policy editors allow you to filter your rule view by affected devices.
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.

Firepower Management Center Configuration Guide, Version 6.3

349
 Deployment Management
Identify Rules with Issues

Procedure

Step 1 In the policy editor, click the Rules tab, 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
Creating and Editing Access Control Rules, on page 1374
Configure Prefiltering, on page 1426
Configuring QoS Rules, on page 696
Configure NAT for Threat Defense, on page 1182

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 a Show Warnings button near the top of the window.
If the system has not identified issues, this button will not appear.
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 checkbox.

Firepower Management Center Configuration Guide, Version 6.3

350
 Deployment Management
Rule and Other Policy Warnings

This will indicate each problem rule in the list with an Error (red) or Warning (yellow) icon.
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 42: Policy Error Icons

Icon Description Example

If a rule or configuration has an A rule that performs category and reputation-based

error, you cannot deploy until you URL filtering is valid until you target a device that
error correct the issue, even if you does not have a URL Filtering license. At that point,
disable any affected rules. an error icon appears next to the rule, and you cannot
deploy until you edit or delete the rule, retarget the
policy, or enable the license.

You can deploy a policy that Preempted rules or rules that cannot match traffic due
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.

Firepower Management Center Configuration Guide, Version 6.3

351
 Deployment Management
Rule Performance Guidelines

Icon Description Example

Information icons convey helpful With application control, the system might skip
information about configurations matching the first few packets of a connection against
information that may affect the flow of traffic. some rules, until the system identifies the application
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
Guidelines and Limitations for Application Control, on page 338
Guidelines and Limitations for URL Filtering, on page 1390

Rule Performance Guidelines

In the Firepower System, rules in various policies exert granular control over network traffic. Properly
configuring and ordering rules is essential to building an effective deployment. Although every organization
and deployment has a unique policy and rule set, there are a few general guidelines to follow that can optimize
performance while still addressing your needs.
Optimizing performance is especially important if you perform resource-intensive analysis. Complex policies
and rules can command significant resources and negatively affect performance. When you deploy configuration
changes, the system evaluates all rules together and creates an expanded set of criteria that target devices use
to evaluate network traffic. If these criteria exceed the resources (physical memory, processors, and so on) of
a target device, you cannot deploy to that device.

Note Always order rules to suit your organization's needs. Place top-priority rules that must apply to all traffic near
the top of the policy. However, rules with application or URL conditions are more likely to match traffic if
you do not prioritize them. This occurs because the system may skip matching the first few packets of a
connection against some rules until the system identifies the application or web traffic in that connection. This
allows connections to be established so that applications and HTTP requests can be identified.

Related Topics
Guidelines and Limitations for Application Control, on page 338
Guidelines and Limitations for URL Filtering, on page 1390

Guidelines for Simplifying and Focusing Rules

Simplify: Do Not Overconfigure
If one condition is enough to match the traffic you want to handle, do not use two.
Minimize individual rule criteria. Use as few individual elements in rule conditions as possible. For example,
in network conditions use IP address blocks rather than individual IP addresses.
Combining elements into objects does not improve performance. For example, using a network object that
contains 50 individual IP addresses gives you only an organizational—not a performance—benefit over
including those IP addresses in the condition individually.

Firepower Management Center Configuration Guide, Version 6.3

352
 Deployment Management
Guidelines for Ordering Rules

For recommendations related to application detection, see Recommendations for Application Control, on page
1369.

Focus: Narrowly Constrain Resource-Intensive Rules, Especially by Interface

As much as possible, use rule conditions to narrowly define the traffic handled by resource-intensive rules.
Focused rules are also important because rules with broad conditions can match many different types of traffic,
and can preempt later, more specific rules. Examples of resource-intensive rules include:
• SSL rules that decrypt traffic—Not only the decryption, but further analaysis of the decrypted traffic,
requires resources. Narrow focus, and where possible, block or choose not to decrypt encrypted traffic.
Certain Firepower Management Center models perform SSL encryption and decryption in hardware,
which improves performance significantly. For more information, see TLS/SSL Hardware Acceleration,
on page 1456.
• Access control rules that invoke deep inspection—Intrusion, file, and malware inspection requires
resources, especially if you use multiple custom intrusion policies and variable sets. Make sure you only
invoke deep inspection where required.

For maximum performance benefit, constrain rules by interface. If a rule excludes all of a device’s interfaces,
that rule does not affect that device's performance.

Guidelines for Ordering Rules

Always order rules to suit your organization's needs. In general, you should place top-priority rules that must
apply to all traffic near the top of the policy.
Exceptions are noted in the sections below.

Rule Preemption
Rule preemption occurs when a rule will never match traffic because a rule earlier in the evaluation order
matches the traffic first. A rule's conditions govern whether it preempts other rules. In the following example,
the second rule cannot block Admin traffic because the first rule allows it:
Access Control Rule 1: allow Admin users
Access Control Rule 2: block Admin users
Any type of rule condition can preempt a subsequent rule. The VLAN range in the first SSL rule includes the
VLAN in the second rule, so the first rule preempts the second:
SSL Rule 1: do not decrypt VLAN 22-33
SSL Rule 2: block VLAN 27
In the following example, Rule 1 matches any VLAN because no VLANs are configured, so Rule 1 preempts
Rule 2, which attempts to match VLAN 2:
Access Control Rule 1: allow Source Network 10.4.0.0/16
Access Control Rule 2: allow Source Network 10.4.0.0/16, VLAN 2
A rule also preempts an identical subsequent rule where all configured conditions are the same:
QoS Rule 1: rate limit VLAN 1 URL www.netflix.com
QoS Rule 2: rate limit VLAN 1 URL www.netflix.com

Firepower Management Center Configuration Guide, Version 6.3

353
 Deployment Management
Rule Actions and Rule Order

A subsequent rule would not be preempted if any condition is different:

QoS Rule 1: rate limit VLAN 1 URL www.netflix.com
QoS Rule 2: rate limit VLAN 2 URL www.netflix.com

Example: Ordering SSL Rules to Avoid Preemption

Consider a scenario where a trusted CA (Good CA) mistakenly issued a CA certificate to a malicious
entity (Bad CA), but has not yet revoked that certificate. You want to use an SSL policy to block
traffic encrypted with certificates issued by the untrusted CA, but otherwise allow traffic within the
trusted CA’s chain of trust. After you upload the CA certificates and all intermediate CA certificates,
configure an SSL policy with rules in the following order:
SSL Rule 1: Block issuer CN=www.badca.com
SSL Rule 2: Do not decrypt issuer CN=www.goodca.com
If you reverse the rules, you first match all traffic trusted by Good CA, including traffic trusted by
Bad CA. Because no traffic ever matches the subsequent Bad CA rule, malicious traffic may be
allowed instead of blocked.

Rule Actions and Rule Order

A rule's action determines how the system handles matching traffic. Improve performance by placing rules
that do not perform or ensure further traffic handling before the resource-intensive rules that do. Then, the
system can divert traffic that it might otherwise have inspected.
The following examples show how you might order rules in various policies, given a set of rules where none
is more critical and preemption is not an issue.
If your rules include application conditions, also see Recommendations for Application Control, on page 1369.

Optimum Order: SSL Rules

Not only does decryption require resources, but so does further analysis of the decrypted traffic. Place SSL
rules that decrypt traffic last.

Note Certain Firepower Management Center hardware models support encrypting and decrypting SSL traffic in
hardware, which significantly improves performance. For more information, see TLS/SSL Hardware
Acceleration, on page 1456.

1. Monitor—Rules that log matching connections, but take no other action on traffic.
2. Block, Block with reset—Rules that block traffic without further inspection.
3. Do not decrypt—Rules that do not decrypt encrypted traffic, passing the encrypted session to access
control rules. The payloads of these sessions are not subject to deep inspection.
4. Decrypt - Known Key—Rules that decrypt incoming traffic with a known private key.
5. Decrypt - Resign—Rules that decrypt outgoing traffic by re-signing the server certificate.

Firepower Management Center Configuration Guide, Version 6.3

354
 Deployment Management
Content Restriction Rule Order

Optimum Order: Access Control Rules

Intrusion, file, and malware inspection requires resources, especially if you use multiple custom intrusion
policies and variable sets. Place access control rules that invoke deep inspection last.
1. Monitor—Rules that log matching connections, but take no other action on traffic.
2. Trust, Block, Block with reset—Rules that handle traffic without further inspection. Note that trusted
traffic is subject to authentication requirements imposed by an identity policy, and to rate limiting.
3. Allow, Interactive Block (no deep inspection)—Rules that do not inspect traffic further, but allow discovery.
Note that allowed traffic is subject to authentication requirements imposed by an identity policy, and to
rate limiting.
4. Allow, Interactive Block (deep inspection)—Rules associated with file or intrusion policies that perform
deep inspection for prohibited files, malware, and exploits.

Content Restriction Rule Order

To avoid rule preemption in both SSL and access control policies, position rules governing YouTube restriction
above rules governing Safe Search restriction.
When you enable Safe Search for an access control rule, the system adds the search engine category to the
Selected Applications and Filters list. This application category includes YouTube. As a result, YouTube
traffic matches to the Safe Search rule unless YouTube EDU is enabled in a rule with a higher evaluation
priority.
A similar rule preemption occurs if you position an SSL rule with the safesearch supported filter higher
in the evaluation order than an SSL rule with specific YouTube application conditions.
Related Topics
About Content Restriction, on page 1443

Application Rule Order

Rules with application conditions are more likely to match traffic if you move them to a lower order in your
list of rules.
Access control rules that use specific conditions (such as networks and IP addresses) should be ordered before
rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect
(OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data
link, and network) should be ordered first in your access control rules. Conditions for layers 5, 6, and 7 (session,
presentation, and application) should be ordered later in your access control rules. For more information about
the OSI model, see this Wikipedia article.
For more information and an example, see Recommendations for Application Control, on page 1369.

SSL Rule Order

In general, order your rules with specific conditions (such as IP addresses and networks) before rules with
general conditions (such as applications).

Allow Traffic from Certificate Pinned Sites

Some applications use a technique referred to as TLS/SSL pinning or certificate pinning, which embeds the
fingerprint of the original server certificate in the application itself. As a result, if you configured a TLS/SSL

Firepower Management Center Configuration Guide, Version 6.3

355
 Deployment Management
URL Rule Order

rule with a Decrypt - Resign action, when the application receives a resigned certificate from a managed
device, validation fails and the connection is aborted.
To confirm that TLS/SSL pinning is occurring, attempt to log in to a mobile application like Facebook. If a
network connection error is displayed, log in using a web browser. (For example, you cannot log in to a
Facebook mobile application but can log in to Facebook using Safari or Chrome.) You can use Firepower
Management Center connection events as further proof of TLS/SSL pinning

Note TLS/SSL pinning is not limited to mobile applications.

To allow this traffic, configure an SSL rule with the Do Not Decrypt action to match the server certificate
common name or distinguished name. In the SSL policy, order this rule before all Decrypt - Resign rules
that also match the traffic. You can retrieve the pinned certificate from the client's browser after a successful
connection to the website. You can also view the certificate from the logged connection event, regardless of
whether the connection succeeded or failed.

Prioritize ClientHello Modifications

To prioritize ClientHello modifications, place rules that match on conditions that are available in the ClientHello
message before rules that match on ServerHello or server Certificate conditions.
When a managed device processes an SSL handshake, it can modify the ClientHello message to increase the
likelihood of decryption. For example, it may remove compression methods because the Firepower System
cannot decrypt compressed sessions.
The system only modifies ClientHello messages if it can conclusively match them to an SSL rule with a
Decrypt - Resign action. The first time the system detects an encrypted session to a new server, server
Certificate data is not available for ClientHello processing, which can result in an undecrypted first session.
For subsequent connections from the same client, the system can match the ClientHello message conclusively
to rules with server Certificate conditions and process the message to maximize decryption potential.
If you place rules that match on ServerHello or server Certificate conditions (certificate, distinguished names,
certificate status, cipher suites, version) before rules that match on ClientHello conditions (zones, networks,
VLAN tags, ports, users, applications, URL categories), you can preempt ClientHello modification and increase
the number of undecrypted sessions.

URL Rule Order

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.

Guidelines for Avoiding Intrusion Policy Proliferation

In an access control policy, you can associate one intrusion policy with each Allow and Interactive Block
rule, as well as with the default action. Every unique pair of intrusion policy and variable set counts as one
policy.

Firepower Management Center Configuration Guide, Version 6.3

356
 Deployment Management
Offload Large Connections (Flows)

However, there is a maximum number of access control rules or intrusion policies that are supported by a
target device. The maximum depends on a number of factors, including policy complexity, physical memory,
and the number of processors on the device.
If you exceed the maximum supported by your device, you cannot deploy your access control policy and must
reevaluate. You may want to consolidate intrusion policies or variable sets so you can associate a single
intrusion policy-variable set pair with multiple access control rules. On some devices you may find you can
use only a single variable set for all your intrusion policies, or even a single intrusion policy-variable set pair
for the whole device.

Offload Large Connections (Flows)

If you deploy Firepower Threat Defense on the Firepower 4100/9300 chassis in a data center, you can enable
select traffic to be offloaded to hardware, which means it is not processed by the software or CPU of your
Firepower Threat Defense device.
You can identify select traffic to be offloaded to a super fast path, where traffic is switched in the NIC itself.
This is called static flow offload. Offloading can help you improve performance for data-intensive applications
such as large file transfers.
• High Performance Computing (HPC) Research sites, where the Firepower Threat Defense device is
deployed between storage and high compute stations. When one research site backs up using FTP file
transfer or file sync over NFS, the large amount of data traffic affects all connections. Offloading FTP
file transfer and file sync over NFS reduces the impact on other traffic.
• High Frequency Trading (HFT), where the Firepower Threat Defense device is deployed between
workstations and the Exchange, mainly for compliance purposes. Security is usually not a concern, but
latency is a major concern.

You can also allow the Firepower Threat Defense to offload flows based on a number of criteria, including
trust. This is called dynamic flow offload.
The Firepower 4100/9300 chassis can offload connections that meet the following criteria:
• (Static flow offload only.) They are fastpathed by the prefilter policy.
• (Dynamic flow offload only.) Inspected flows that the inspection engine decides no longer need inspection.
These flows include:
• Flows that match an access control policy's Trust rule action.
• Flows that are trusted by the Intelligent Application Bypass (IAB) policy either explicitly or due to
exceeding flow bypass thresholds.
• Flows that match file or intrusion policies that result in trusting the flow.

• IPv4 addresses only.

• TCP, UDP, GRE only.

Note PPTP GRE connections are not offloaded.

• Standard or 802.1Q tagged Ethernet frames only.

Firepower Management Center Configuration Guide, Version 6.3

357
 Deployment Management
Flow Offload Limitations

• Switched or routed interfaces only. Not supported on passive, inline, or inline tap interfaces.

In addition, dynamic flow offload supports the following:

• Secondary connection wherever possible; for example, FTP data transfers.
• The following IPS preprocessor inspected flows:
• SSL, SSH and SMTP.
• FTP preprocessor secondary connections.
• Session Initiation Protocol (SIP) preprocessor secondary connections.

• Intrusion rules that use keywords (also referred to as options)

• Intelligent Application Bypass (IAB), which identifies applications that you trust to traverse your network
without further inspection if certain conditions are met.

Use Static Flow Offload

To identify a flow as being eligible for offload, create a prefilter policy rule that applies the Fastpath action.
Use prefilter rules for TCP/UDP, and tunnel rules for GRE. Incidentally, if you configure access control rules
to apply the Trust action based on security zone, source and destination network and port matching only, and
you disable Security Intelligence, flows matching those rules are also eligible for offloading.
Once a connection is established, if it is eligible to be offloaded, further processing happens in the NIC rather
than in the Firepower Threat Defense software. Offloaded flows continue to receive limited stateful inspection,
such as basic TCP flag and option checking. The system can selectively escalate packets to the firewall system
for further processing if necessary.
Reverse flows for offloaded flows are also offloaded.

Use Dynamic Flow Offload

Dynamic flow offload is enabled by default.

Note If more than one flow that matches dynamic flow offload conditions are queued to be offloaded at the same
time, a collision occurs. In the case of a collision, only the first flow is offloaded. The other flows are processed
normally. The show flow-offload flow commands display collision statistics.

Following is an example of disabling dynamic offload:

> configure flow-offload dynamic whitelist disable

Following is an example of enabling dynamic offload:

> configure flow-offload dynamic whitelist enable

Flow Offload Limitations

Not all flows can be offloaded. Even after offload, a flow can be removed from being offloaded under certain
conditions. Following are some of the limitations:

Firepower Management Center Configuration Guide, Version 6.3

358
Deployment Management
Flow Offload Limitations

Flows that cannot be offloaded

The following types of flows cannot be offloaded.
• Flows that use IPv6 addressing.
• Flows for any protocol other than TCP, UDP, and GRE.

Note PPTP GRE connections cannot be offloaded.

• Flows on interfaces configured in passive, inline, or inline tap mode. Routed and switch interfaces
are the only types supported.
• Flows that require inspection by Snort or other inspection engines. In some cases, such as FTP, the
secondary data channel can be offloaded although the control channel cannot be offloaded.
• IPsec and VPN connections.
• Flows for which you decrement the time-to-live (TTL) value.
• Flows that require encryption or decryption.
• Multicast flows.
• TCP Intercept flows.
• AAA-related flows.
• Vpath, VXLAN related flows.
• URL filtering.
• Tracer flows.
• Flows tagged with security groups.
• Reverse flows that are forwarded from a different cluster node, in case of asymmetric flows in a
cluster.
• Centralized flows in a cluster, if the flow owner is not the master.

Additional flows that cannot be dynamically offloaded

Flows that include IP options cannot be dynamically offloaded.
Dynamic flow offload disables all TCP normalizer checks.
Conditions for reversing offload
After a flow is offloaded, packets within the flow are returned to the Firepower Threat Defense device
for further processing if they meet the following conditions:
• They include TCP options other than Timestamp.
• They are fragmented.
• They are subject to Equal-Cost Multi-Path (ECMP) routing, and ingress packets move from one
interface to another.

Firepower Management Center Configuration Guide, Version 6.3

359
 Deployment Management
History for Rule Management: Common Characteristics

History for Rule Management: Common Characteristics

Feature Version Details

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 1389.

Firepower Management Center Configuration Guide, Version 6.3

360
 CHAPTER 18
Reusable Objects
The following topics describe how to manage reusable objects in the Firepower System:
• Introduction to Reusable Objects, on page 362
• The Object Manager, on page 364
• Network Objects, on page 371
• Port Objects, on page 373
• Tunnel Zones, on page 375
• Application Filters, on page 375
• VLAN Tag Objects, on page 375
• Security Group Tag Objects, on page 376
• URL Objects, on page 377
• Geolocation Objects, on page 378
• Interface Objects: Interface Groups and Security Zones, on page 379
• Time Range Objects, on page 381
• Variable Sets, on page 382
• Security Intelligence Lists and Feeds, on page 398
• Sinkhole Objects, on page 406
• File Lists, on page 407
• Cipher Suite Lists, on page 412
• Distinguished Name Objects, on page 413
• PKI Objects, on page 415
• DNS Server Group Objects, on page 431
• SLA Monitor Objects, on page 432
• Prefix Lists, on page 434
• Route Maps, on page 436
• Access List, on page 439
• AS Path Objects, on page 442
• Community Lists, on page 442
• Policy Lists, on page 444
• VPN Objects, on page 445
• Address Pools, on page 458
• FlexConfig Objects, on page 459
• RADIUS Server Groups, on page 459

Firepower Management Center Configuration Guide, Version 6.3

361
 Deployment Management
Introduction to Reusable Objects

Introduction to Reusable Objects

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

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

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

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

Object Type Groupable? Allows Overrides?

Network yes yes

Port yes yes

Interface: no no
• Security Zone
• Interface Group

Tunnel Zone no no

Application Filter no no

VLAN Tag yes yes

Security Group Tag (SGT) no no

URL yes yes

Firepower Management Center Configuration Guide, Version 6.3

362
Deployment Management
Introduction to Reusable Objects

Object Type Groupable? Allows Overrides?

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

DNS Server Group no no

SLA Monitor no no

Prefix List: IPv4 and IPv6 no yes

Route Map no yes

Access List: Standard and Extended no yes

AS Path no yes

Community List no yes

Policy List no yes

FlexConfig: Text and FlexConfig objects no yes

Objects and Multitenancy

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

Firepower Management Center Configuration Guide, Version 6.3

363
 Deployment Management
The Object Manager

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

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

The Object Manager

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

Editing Objects
Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

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 1 Choose Objects > Object Management.

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

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

Firepower Management Center Configuration Guide, Version 6.3

364
 Deployment Management
Filtering Objects or Object Groups

If a view icon ( ) 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 394.
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 369. You can change this setting only for objects that belong to the current domain.
• If you want to add override values to this object, expand the Override section and click Add; see Adding
Object Overrides, on page 370.

Step 7 Click Save.

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

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

Filtering Objects or Object Groups

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

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

Procedure

Step 1 Choose Objects > Object Management.

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 metacharacters:
• 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.

Firepower Management Center Configuration Guide, Version 6.3

365
 Deployment Management
Sorting Objects

Sorting Objects
Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

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 1 Choose Objects > Object Management.

Step 2 Click a column heading. To sort in the opposite direction, click the heading again.

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

Grouping Reusable Objects

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

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

Firepower Management Center Configuration Guide, Version 6.3

366
Deployment Management
Grouping Reusable Objects

Procedure

Step 1 Choose Objects > Object Management.

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

c) Click the Add [Object Type] Group button.

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 to search for existing objects to include, which updates as you type to display
matching items. Click the reload icon above the search field or click the clear icon ( ) in the search
field to clear the search string.

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

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

Step 8 Click Save.

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

Firepower Management Center Configuration Guide, Version 6.3

367
 Deployment Management
Object Overrides

Object Overrides
An object override allows you to define an alternate value for an object, which the system uses for the devices
you specify.
You can create an object whose definition works for most devices, and then use overrides to specify
modifications to the object for the few devices that need different definitions. You can also create an object
that needs to be overridden for all devices, but its use allows you to create a single policy for all devices.
Object overrides allow you to create a smaller set of shared policies for use across devices without giving up
the ability to alter policies when needed for individual devices.
For example, you might want to deny ICMP traffic to the different departments in your company, each of
which is connected to a different network. You can do this by defining an access control policy with a rule
that includes a network object called Departmental Network. By allowing overrides for this object, you can
then create overrides on each relevant device that specifies the actual network where that device is connected.
In a multidomain deployment, you can define a default value for an object in an ancestor domain and allow
administrators in descendant domains to add override values for that object. For example, a managed security
service provider (MSSP) might use a single Firepower Management Center to manage network security for
multiple customers. Administrators at the MSSP can define an object in the Global domain for use in all
customers' deployments. Administrators for each customer can log into descendant domains to override that
object for their organizations. These local administrators cannot view or affect the override values of other
customers of the MSSP.
You can target an object override to a specific domain. In this case, the system uses the object override value
for all devices in the targeted domain unless you override it at the device level.
From the object manager, you can choose an object that can be overridden and define a list of device-level or
domain-level overrides for that object.
You can use object overrides with the following object types only:
• Network
• Port
• VLAN tag
• URL
• SLA Monitor
• Prefix List
• Route Map
• Access List
• AS Path
• Community List
• Policy List
• PKI Enrollment

If you can override an object, the Override column appears for the object type in the object manager. Possible
values for this column include:

Firepower Management Center Configuration Guide, Version 6.3

368
 Deployment Management
Managing Object Overrides

• 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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

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

If a view icon ( ) 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 370.
• Allow—Allow object overrides; see Allowing Object Overrides, on page 369.
• Delete—In the object editor, click the delete icon ( ) next to the override you want to remove.
• Edit—Edit object overrides; see Editing Object Overrides, on page 370.

Allowing Object Overrides

Smart License Classic License Supported Devices Supported Domains Access
Any Any Any Any Admin/Access
Admin/Network
Admin

Procedure

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

Firepower Management Center Configuration Guide, Version 6.3

369
 Deployment Management
Adding Object Overrides

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

Adding Object Overrides

Smart License Classic License Supported Devices Supported Domains Access
Any Any Any Any Admin/Access
Admin/Network
Admin

Before you begin

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

Procedure

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

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

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

Editing Object Overrides

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

370
 Deployment Management
Network Objects

Procedure

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

Step 2 Click the edit icon ( ) next to the override you want to modify.
Step 3 Optionally, modify the Description.
Step 4 Modify the override value.
Step 5 Click Save to save the override.
Step 6 Click Save to save the object.

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

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

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

Range
A range of IP addresses.
IPv4 example:
209.165.200.225-209.165.200.250

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

Network
An address block, also known as a subnet.

Firepower Management Center Configuration Guide, Version 6.3

371
 Deployment Management
Creating Network Objects

IPv4 example:
209.165.200.224/27

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

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

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

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

Firepower Management Center Configuration Guide, Version 6.3

372
 Deployment Management
Port Objects

Step 4 Enter a Name.

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

Step 5 Optionally, enter a Description.

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

Step 9 Click Save.

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

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

Firepower Management Center Configuration Guide, Version 6.3

373
 Deployment Management
Creating Port Objects

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

Creating Port Objects

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

Step 7 Manage overrides for the object:

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

Step 8 Click Save.

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

Firepower Management Center Configuration Guide, Version 6.3

374
 Deployment Management
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 1431.

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 334.

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin

Access Admin
Network Admin

Procedure

Step 1 Choose Objects > Object Management.

Step 2 Choose VLAN Tag from the list of object types.
Step 3 Choose Add Object from the Add VLAN Tag drop-down list.
Step 4 Enter a Name.
Step 5 Enter a Description.
Step 6 Enter a value in the VLAN Tag field. Use a hyphen to specify a range of VLAN tags.
Step 7 Manage overrides for the object:

Firepower Management Center Configuration Guide, Version 6.3

375
 Deployment Management
Security Group Tag Objects

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

Step 8 Click Save.

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

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 347
Custom SGT Conditions, on page 346
ISE SGT vs Custom SGT Rule Conditions, on page 347

Creating Security Group Tag Objects

Smart License Classic License Supported Devices Supported Domains Access

Any Control Any Global only Admin/Access

Admin/Network
Admin

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 Choose Objects > Object Management.

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

Firepower Management Center Configuration Guide, Version 6.3

376
 Deployment Management
URL Objects

Step 7 Click Save.

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

Related Topics
Autotransition from Custom SGTs to ISE SGTs, on page 347
Custom SGT Conditions, on page 346
ISE SGT vs Custom SGT Rule Conditions, on page 347

URL Objects
Each URL object you configure represents a single URL or IP address. You can use URL objects and groups
in various places in the system’s web interface, including access control policies and event searches. For
example, you could write an access control rule that blocks a specific website.
When creating URL objects, especially if you do not configure SSL inspection to decrypt or block encrypted
traffic, keep the following points in mind:
• If you plan to use a URL object to match HTTPS traffic in an access control rule, create the object using
the subject common name in the public key certificate used to encrypt the traffic. Also, the system
disregards subdomains within the subject common name, so do not include subdomain information. For
example, use example.com rather than www.example.com.
• When matching web traffic using access control rules with URL conditions, the system disregards the
encryption protocol (HTTP vs HTTPS). In other words, if you block a website, both HTTP and HTTPS
traffic to that website is blocked, unless you use an application condition to refine the rule. When creating
a URL object, you do not need to specify the protocol when creating an object. For example, use
example.com rather than http://example.com/.

Creating URL Objects

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

Step 2 Choose URL from the list of object types.
Step 3 Choose Add Object from the Add URL drop-down list.
Step 4 Enter a Name.

Firepower Management Center Configuration Guide, Version 6.3

377
 Deployment Management
Geolocation Objects

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

Step 5 Optionally, enter a Description.

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

Step 8 Click Save.

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

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

Firepower Management Center Configuration Guide, Version 6.3

378
 Deployment Management
Interface Objects: Interface Groups and Security Zones

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

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

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 1431.
All interfaces in an interface object must be of the same type: all inline, passive, switched, routed, or ASA
FirePOWER. After you create an interface object, you cannot change the type of interfaces it contains.
The Interface Objects page of the object manager lists the security zones and interface groups configured on
your managed devices. The page also displays the type of interfaces in each interface object, and you can
expand each interface object to view which interfaces on which devices belong to each object.

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

Model-Specific Notes and Warnings

During initial configuration of a 7000 or 8000 Series device, the system creates security zones based on the
detection mode you selected for the device. For example, the system creates a Passive zone in passive
deployments, while in inline deployments the system creates External and Internal zones. When you register
the device to the Firepower Management Center, those security zones are added to the FMC.
If you modify ASA FirePOWER security contexts, switching from single context mode to multi-context mode
or vice versa, the system removes all the device's interfaces from their assigned security zones.

Firepower Management Center Configuration Guide, Version 6.3

379
 Deployment Management
Creating Security Zone and Interface Group Objects

Interface Objects and Multitenancy

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

Creating Security Zone and Interface Group Objects

Smart License Classic License Supported Devices Supported Domains Access

Any Any Security Zones: Any Any Admin/Access

Admin/Network
Interface Groups:
Admin
Firepower Threat
Defense

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 379.
• 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 1 Choose Objects > Object Management.

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

Step 7 Choose one or more interfaces.

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

Firepower Management Center Configuration Guide, Version 6.3

380
 Deployment Management
Time Range Objects

Step 9 Click Save.

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

Time Range Objects

Use a time range object to apply a policy only during times you specify.

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.
You can specify time range objects only in VPN Group Policy objects.

Procedure

Step 1 Choose Objects > Object Management.

Step 2 Choose Time Range from the list of object types.
Step 3 Click Add Time Range.
Step 4 Enter values.
Observe the following guidelines:
• If you see a red error box around the object name you have entered, mouse over the Name field to see
naming restrictions.
• All times are in UTC.
• Enter times using a 24-hour clock. For example, enter 1:30 PM as 13:30.
• To specify a single continuous range, such as typical weekend hours (Fridays at 5pm through Mondays
at 8am, including evenings and nights), choose Range Type Range.
• To specify part of multiple days, such as Monday through Friday from 8am to 5pm (excluding evenings,
nights, and early mornings every day), choose Range Type Daily Interval.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

381
 Deployment Management
Variable Sets

Step 5 Click Save.

What to do next
Specify the time range object in a VPN group policy object using the Access Hours field.
For details, see Configure Group Policy Objects, on page 451 and Group Policy Advanced Options, on page
455.

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

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

You use variable sets to manage, customize, and group your variables. You can use the default variable set
provided by the system or create your own custom sets. Within any set you can modify predefined default
variables and add and modify user-defined variables.
Most of the shared object rules and standard text rules that the Firepower System provides use predefined
default variables to define networks and port numbers. For example, the majority of the rules use the variable
$HOME_NET to specify the protected network and the variable $EXTERNAL_NET to specify the unprotected (or
outside) network. In addition, specialized rules often use other predefined variables. For example, rules that
detect exploits against web servers use the $HTTP_SERVERS and $HTTP_PORTS variables.
Rules are more effective when variables more accurately reflect your network environment. At a minimum,
you should modify default variables in the default set. By ensuring that a variable such as $HOME_NET correctly
defines your network and $HTTP_SERVERS includes all web servers on your network, processing is optimized
and all relevant systems are monitored for suspicious activity.
To use your variables, you link variable sets to intrusion policies associated with access control rules or with
the default action of an access control policy. By default, the default variable set is linked to all intrusion
policies used by access control policies.
Adding a variable to any set adds it to all sets; that is, each variable set is a collection of all variables currently
configured on your system. Within any variable set, you can add user-defined variables and customize the
value of any variable.
Initially, the Firepower System provides a single, default variable set comprised of predefined default values.
Each variable in the default set is initially set to its default value, which for a predefined variable is the value
set by the Cisco Talos Security Intelligence and Research 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.

Firepower Management Center Configuration Guide, Version 6.3

382
 Deployment Management
Variable Sets in Intrusion Policies

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 394
Managing Variable Sets, on page 393

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.

Firepower Management Center Configuration Guide, Version 6.3

383
 Deployment Management
Predefined Default Variables

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

Predefined Default Variables

By default, the Firepower System provides a single default variable set, which is comprised of predefined
default variables. The Cisco Talos Security Intelligence and Research 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 43: 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.

Firepower Management Center Configuration Guide, Version 6.3

384
 Deployment Management
Predefined Default Variables

Variable Name Description Modify?

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.

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

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

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

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

Defines 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.

Firepower Management Center Configuration Guide, Version 6.3

385
 Deployment Management
Network Variables

Variable Name Description Modify?

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

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

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

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

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

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

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

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

Network Variables
Network variables represent IP addresses you can use in intrusion rules that you enable in an intrusion policy
and in intrusion policy rule suppressions, dynamic rule states, and adaptive profile updates. Network variables
differ from network objects and network object groups in that network variables are specific to intrusion
policies and intrusion rules, whereas you can use network objects and groups to represent IP addresses in
various places in the system’s web interface, including access control policies, network variables, intrusion
rules, network discovery rules, event searches, reports, and so on.
You can use network variables in the following configurations to specify the IP addresses of hosts on your
network:

Firepower Management Center Configuration Guide, Version 6.3

386
Deployment Management
Network Variables

• intrusion rules—Intrusion rule Source IPs and Destination IPs header fields allow you to restrict packet
inspection to the packets originating from or destined to specific IP addresses.
• suppressions—The Network field in source or destination intrusion rule suppressions allows you to
suppress intrusion event notifications when a specific IP address or range of IP addresses triggers an
intrusion rule or preprocessor.
• dynamic rule states—The Network field in source or destination dynamic rule states allows you to detect
when too many matches for an intrusion rule or preprocessor rule occur in a given time period.
• adaptive profile updates—When you enable adaptive profile updates, the adaptive profiles Networks
field identifies hosts where you want to improve reassembly of packet fragments and TCP streams in
passive deployments.

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

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

Firepower Management Center Configuration Guide, Version 6.3

387
 Deployment Management
Port Variables

• Excluded values must resolve to a subset of included values. For example, you cannot include the address
block 192.168.5.0/24 and exclude 192.168.6.0/24.

Port Variables
Port variables represent TCP and UDP ports you can use in the Source Port and Destination Port header
fields in intrusion rules that you enable in an intrusion policy. Port variables differ from port objects and port
object groups in that port variables are specific to intrusion rules. You can create port objects for protocols
other than TCP and UDP, and you can use port objects in various places in the system’s web interface, including
port variables, access control policies, network discovery rules, and event searches.
You can use port variables in the intrusion rule Source Port and Destination Port header fields to restrict
packet inspection to packets originating from or destined to specific TCP or UDP ports.
When you use variables in these fields, the variable set you link to the intrusion policy associated with an
access control rule or policy determines the values for these variables in the network traffic where you deploy
the access control policy.
You can add any combination of the following port configurations to a variable:
• any combination of port variables and port objects that you select from the list of available ports
Note that the list of available ports does not display port object groups, and you cannot add these to
variables.
• individual port objects that you add from the New Variable or Edit Variable page, and can then add to
your variable and to other existing and future variables
Only TCP and UDP ports, including the value any for either type, are valid variable values. If you use
the new or edit variables page to add a valid port object that is not a valid variable value, the object is
added to the system but is not displayed in the list of available objects. When you use the object manager
to edit a port object that is used in a variable, you can only change its value to a valid variable value.
• single, literal port values and port ranges
You must separate port ranges with a dash (-). Port ranges indicated with a colon (:) are supported for
backward compatibility, but you cannot use a colon in port variables that you create.
You can list multiple literal port values and ranges by adding each individually in any combination.

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.

Firepower Management Center Configuration Guide, Version 6.3

388
 Deployment Management
Advanced Variables

• Excluded values must resolve to a subset of included values. For example, you cannot include the port
range 10-50 and exclude port 60.

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

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

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

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

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

Table 44: 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.

Firepower Management Center Configuration Guide, Version 6.3

389
 Deployment Management
Adding Variables to Sets

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 do 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.

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.

Firepower Management Center Configuration Guide, Version 6.3

390
 Deployment Management
Example: Adding User-Defined Variables to Custom Sets

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.

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 —

Firepower Management Center Configuration Guide, Version 6.3

391
 Deployment Management
Nesting Variables

Variable Type Included Networks Excluded Networks

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.

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

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.

Variable Type Included Networks Excluded 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

Firepower Management Center Configuration Guide, Version 6.3

392
 Deployment Management
Managing Variable Sets

Alternative to an Unsupported Nested, Negated Variable

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

Variable Type Included Networks Excluded Networks

HOME_NET customized default 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

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

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 1 Choose Objects > Object Management.

Step 2 Choose Variable Set from the list of object types.
Step 3 Manage your variable sets:
• Add — If you want to add a custom variable set, click Add Variable Set; see Creating Variable Sets,
on page 394.
• Delete — If you want to delete a custom variable set, click the delete icon ( ) 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 the edit icon ( ) next to the variable set you want to
modify; see Editing Objects, on page 364.
• 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 the clear icon ( ) in the filter field.

Firepower Management Center Configuration Guide, Version 6.3

393
 Deployment Management
Creating Variable Sets

• Manage Variables — To manage the variables included in variable sets, see Managing Variables, on
page 394.

Creating Variable Sets

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

Step 5 Optionally, enter a Description.

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

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

Managing Variables
Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

394
Deployment Management
Managing Variables

Procedure

Step 1 Choose Objects > Object Management.

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

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

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

Step 4 Manage your variables:

• Display — If you want to display the complete value for a variable, hover your pointer over the value
in the Value column next to the variable.
• Add — If you want to add a variable, click Add; see Adding Variables, on page 396.
• Delete — Click the delete icon ( ) 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 the edit icon ( ) next to the variable you want to edit; see Editing Variables, on page 397.
• Reset — If you want to reset a modified variable to its default value, click the reset icon ( ) next to a
modified variable. If the reset icon 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 icon to display the default value.

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

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

Firepower Management Center Configuration Guide, Version 6.3

395
 Deployment Management
Adding Variables

Adding Variables
Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

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 the delete icon ( ) next to the
item.
Note The list of items to include or exclude can be comprised of any combination of literal strings and
existing variables, objects, and network object groups in the case of network variables.

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

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

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

Firepower Management Center Configuration Guide, Version 6.3

396
 Deployment Management
Editing Variables

Editing Variables
Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

In a multidomain deployment, the system displays objects created in the current domain, which you can edit.
It also displays objects created in ancestor domains, which in most cases you cannot edit. To view and edit
objects in a descendant domain, switch to that domain.
You can edit both custom and default variables.
You cannot change the Name or Type values in an existing variable.

Procedure

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

If a view icon ( ) 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 the delete icon next to the
item.
Note The list of items to include or exclude can be comprised of any combination of literal strings and
existing variables, objects, and network object groups in the case of network variables.

Step 3 Click Save to save the variable.

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

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

Firepower Management Center Configuration Guide, Version 6.3

397
 Deployment Management
Security Intelligence Lists and Feeds

Security Intelligence Lists and Feeds

Security Intelligence lists and feeds help you quickly filter traffic by collecting:
• IP address and address blocks—Use in access control policies to blacklist and whitelist as part of Security
Intelligence.
• Domain Names—Use in DNS policies to blacklist and whitelist as part of Security Intelligence.
• URLs—Use in access control policies to blacklist and whitelist 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.

Lists
A list is a static collection that you manage manually.
By default, access control and DNS policies use Global blacklists and whitelists as part of Security Intelligence.
Whitelist Now and Blacklist Now actions allow you to build and implement these lists; see Blacklist Now,
Whitelist Now, and Global Lists, on page 399.
Custom lists can augment and fine-tune feeds and the Global lists.

Feeds
A feed is a dynamic collection that updates on an interval over HTTP or HTTPS.
The regularly updated Cisco Intelligence Feed allows you to filter network traffic based on the latest threat
intelligence from Talos. You can also use third-party feeds. Or, with a custom internal feed, you could easily
maintain an enterprise-wide blacklist in a large deployment with multiple Firepower Management Center
appliances.
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.

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

398
 Deployment Management
Security Intelligence Object Quick Reference

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.

List and Feed Updates

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.

Security Intelligence Object Quick Reference

Object Type Edit Capabilities Requires Redeploy After Edit?

Default (but custom-populated) Add entries using the context menu. No after adding entries.
whitelists and blacklists: Global,
Delete entries using the object Yes after deleting entries.
descendant, and domain-specific
manager.

Custom whitelists and blacklists Upload new and replacement lists Yes
using the object manager.

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.

Blacklist Now, Whitelist Now, and Global Lists

The Firepower Management Center context menu (see The Context Menu, on page 31) allows you to quickly
blacklist and whitelist with Security Intelligence. For example, if you notice a set of routable IP addresses in
intrusion events associated with exploit attempts, you can immediately blacklist those IP addresses. Although
it may take a few minutes for your changes to propagate, you do not have to redeploy.
Blacklist Now and Whitelist Now context-menu options are available on IP address, URL, and DNS request
hotspots. Blacklisting or whitelisting with the context menu adds the chosen item to the appropriate default
Global list. By default, Access control and DNS policies use these Global lists, which apply to all security
zones. You can opt not to use these lists on a per-policy basis.

Note These options apply to Security Intelligence only. Security Intelligence cannot blacklist traffic that has already
been fastpathed. Similarly, Security Intelligence whitelisting does not automatically trust or fastpath matching
traffic. For more information, see About Security Intelligence, on page 1405.

Firepower Management Center Configuration Guide, Version 6.3

399
 Deployment Management
Security Intelligence Lists and Multitenancy

Context Menu Option Target Item Affected Global Lists

Blacklist Now An IP address Global Blacklist

Whitelist Now Global Whitelist

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

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

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

In a multidomain deployment, you can choose the Firepower System domains where you want to enforce the
blacklisting or whitelisting by adding items to Domain lists as well as the Global lists; see Security Intelligence
Lists and Multitenancy, on page 400.
Because adding an entry to a Security Intelligence list affects access control, you must have one of:
• Administrator access
• A combination of default 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

Security Intelligence Lists and Multitenancy

In a multidomain deployment, the Global domain owns the Global blacklists and whitelists. Only Global
administrators can add to or remove items from the Global lists. So that subdomain users can whitelist and
blacklist networks, domain names, and URLs, multitenancy adds:
• Domain lists—Whitelists or blacklists whose contents apply to a particular subdomain only. The Global
lists are Domain lists for the Global domain.
• Descendant Domain lists—Whitelists or blacklists 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 Blacklist - Company A and Domain Whitelist - Company A
• Domain Blacklist for DNS - Company A, Domain Whitelist for DNS - Company A
• Domain Blacklist for URL - Company A, Domain Whitelist for URL - Company A

Firepower Management Center Configuration Guide, Version 6.3

400
 Deployment Management
Changing the Update Frequency for Security Intelligence Feeds

Any administrator at or above the current domain can populate these lists. You can use the context menu to
whitelist or blacklist an item 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 blacklist the same IP address in the Global domain and
Company A’s domain, but not blacklist it in Company B’s domain. This action would add the same IP address
to:
• Global Blacklist (where it can be removed only by Global administrators)
• Domain Blacklist - 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 multi-domain deployment, using literal
IP addresses to constrain this configuration can have unexpected results.

Descendant Domain Lists

A Descendant Domain list is a whitelist or blacklist that aggregates the Domain lists of the current domain’s
descendants. Leaf domains do not have Descendant Domain lists.
Descendant Domain lists are useful because a higher-level domain administrator can enforce general Security
Intelligence settings, while still allowing subdomain users to blacklist and whitelist items in their own
deployment.
For example, the Global domain has the following Descendant Domain lists:
• Descendant Blacklists - Global, Descendant Whitelists - Global
• Descendant Blacklists for URL - Global, Descendant Whitelists for URL - Global
• Descendant Blacklists for URL - Global, Descendant Whitelists 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.

Changing the Update Frequency for Security Intelligence Feeds

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

By default, each feed updates the Management Center every two hours. You cannot delete the system-provided
feeds, but you can change the frequency of (or disable) their updates.
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.

Firepower Management Center Configuration Guide, Version 6.3

401
 Deployment Management
Custom Security Intelligence Feeds

Note The Management Center pushes Security Intelligence updates to managed devices every 30 minutes. You
cannot modify this frequency.

Procedure

Step 1 Choose Objects > Object Management.

Step 2 Expand the Security Intelligence node, then choose the feed type whose frequency you want to change.

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

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

Step 4 Edit the Update Frequency.

Step 5 Click Save.

Custom Security Intelligence Feeds

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

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

When you configure a feed, you specify its location using a URL; the URL cannot be Punycode-encoded. By
default, the system downloads the entire feed source on the interval you configure, then automatically updates
its managed devices.
You also can configure the system to use an md5 checksum to determine whether to download an updated
feed. If the checksum has not changed since the last time the system downloaded the feed, the system does
not need to re-download it. You may want to use md5 checksums for internal feeds, especially if they are
large. The md5 checksum must be stored in a simple text file with only the checksum. Comments are not
supported.
Manually updating Security Intelligence feeds updates all feeds, including the Intelligence Feeds.

Firepower Management Center Configuration Guide, Version 6.3

402
 Deployment Management
Creating Security Intelligence Feeds

Creating Security Intelligence Feeds

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

Step 4 Enter a Name for the feed.

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

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

Step 6 Enter a Feed URL.
Step 7 Optionally, enter an MD5 URL.
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

Smart License Classic License Supported Devices Supported Domains Access

Threat (Security Protection (Security Any Any Admin/Access

Intelligence) Intelligence) Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

Firepower Management Center Configuration Guide, Version 6.3

403
 Deployment Management
Custom Security Intelligence Lists

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 whitelist that contains only the improperly classified IP addresses, rather
than removing the IP address feed object from the access control policy’s blacklist.

Note You cannot whitelist or blacklist address blocks 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.

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.
• If you add a URL ending in a forward slash (/) character to a URL list, only exact URLs match that entry.
• If you add a URL that does not end in a forward slash to a URL or DNS list, any URL that shares the
same common prefix matches that entry. For example, if you add www.example.com to a URL list, the
system matches both www.example.com and www.example.com/example.

Uploading New Security Intelligence Lists to the Firepower Management Center

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Firepower Management Center Configuration Guide, Version 6.3

404
 Deployment Management
Updating Security Intelligence Lists

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 1 Choose Objects > Object Management.

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

Step 4 Enter a Name.

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

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

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

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

Updating Security Intelligence Lists

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

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 1 Choose Objects > Object Management.

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

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

Firepower Management Center Configuration Guide, Version 6.3

405
 Deployment Management
Sinkhole Objects

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

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

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

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

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

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

Firepower Management Center Configuration Guide, Version 6.3

406
 Deployment Management
File Lists

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

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

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

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.

Firepower Management Center Configuration Guide, Version 6.3

407
 Deployment Management
Adding Individual SHA-256 Values to File Lists

• All non-duplicate SHA-256 values are added to the file list. If a file list contains a SHA-256 value, and
you upload a source file containing that value, the newly uploaded value does not modify the existing
SHA-256 value. When viewing captured files, file events, or malware events related to the SHA-256
value, any threat name or description is derived from the individual SHA-256 value.
• The system does not upload invalid SHA-256 values in a source file.
• If multiple uploaded source files contain an entry for the same SHA-256 value, the system uses the most
recent value.
• If a source file contains multiple entries for the same SHA-256 value, the system uses the last one.
• You cannot directly edit a source file within the object manager. To make changes, you must first modify
your source file directly, delete the copy on the system, then upload the modified source file.
• The number of entries associated with a source file refers to the number of distinct SHA-256 values. If
you delete a source file from a file list, the total number of SHA-256 entries the file list contains decreases
by the number of valid entries in the source file.

Adding Individual SHA-256 Values to File Lists

Smart License Classic License Supported Devices Supported Domains Access

Malware Malware Firepower Any Admin/Network

Admin/Access
Admin

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

Before you begin

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

Procedure

Step 1 Choose Objects > Object Management.

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

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

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

Step 4 Choose Enter SHA Value from the Add by drop-down list.
Step 5 Enter a description of the source file in the Description field.

Firepower Management Center Configuration Guide, Version 6.3

408
 Deployment Management
Uploading Individual Files to File Lists

Step 6 Enter or paste the file’s entire value in the SHA-256 field. The system does not support matching partial
values.
Step 7 Click Add.
Step 8 Click Save.

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

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

Smart License Classic License Supported Devices Supported Domains Access

Malware Malware Any Any Admin/Access

Admin/Network
Admin

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

Procedure

Step 1 Choose Objects > Object Management.

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

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

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

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

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

Firepower Management Center Configuration Guide, Version 6.3

409
 Deployment Management
Uploading Source Files to File Lists

Step 8 Click Save.

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

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

Smart License Classic License Supported Devices Supported Domains Access

Malware Malware Any Any Admin/Access

Admin/Network
Admin

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 1 Choose Objects > Object Management.

Step 2 Click File List.

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

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

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

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

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

Firepower Management Center Configuration Guide, Version 6.3

410
 Deployment Management
Editing SHA-256 Values in File Lists

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

Smart License Classic License Supported Devices Supported Domains Access

Malware Malware Any Any Admin/Access

Admin/Network
Admin

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

Procedure

Step 1 Choose Objects > Object Management.

Step 2 Click File List.

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

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

Step 4 You can:

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

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

Step 6 Click Save to save the file list.

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

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

Firepower Management Center Configuration Guide, Version 6.3

411
 Deployment Management
Downloading Source Files from File Lists

Downloading Source Files from File Lists

Smart License Classic License Supported Devices Supported Domains Access

Malware Malware Any Any Admin/Access

Admin/Network
Admin

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 1 Choose Objects > Object Management.

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

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

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

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

Cipher Suite Lists

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

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.

Firepower Management Center Configuration Guide, Version 6.3

412
 Deployment Management
Creating Cipher Suite Lists

Creating Cipher Suite Lists

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except NGIPSv Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

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

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

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

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.
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.

Firepower Management Center Configuration Guide, Version 6.3

413
 Deployment Management
Distinguished Name Objects

Table 45: Distinguished Name Attributes

Attribute Description Allowed Values

C Country Code two alphabetic characters

CN Common Name up to 64 alphanumeric, backslash

(/), hyphen (-), quotation ("), or
asterisk (*) characters, or spaces

O Organization up to 64 alphanumeric, backslash

(/), hyphen (-), quotation ("), or
asterisk (*) characters, or spaces

OU Organizational Unit up to 64 alphanumeric, backslash

(/), hyphen (-), quotation ("), or
asterisk (*) characters, or spaces

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 46: 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

CN=”*.*.com” mail.example.com example.com

example.text.com ampleexam.com

Firepower Management Center Configuration Guide, Version 6.3

414
 Deployment Management
Creating Distinguished Name Objects

Creating Distinguished Name Objects

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except NGIPSv Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

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

Step 6 Click Save.

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

PKI Objects
PKI Objects for SSL Application
PKI objects represent the public key certificates and paired private keys required to support your deployment.
Internal and trusted CA objects consist of certificate authority (CA) certificates; internal CA objects also
contain the private key paired with the certificate. Internal and external certificate objects consist of server
certificates; internal certificate objects also contain the private key paired with the certificate.
If you use trusted certificate authority objects and internal certificate objects to configure a connection to
ISE/ISE-PIC, you can use ISE/ISE-PIC as an identity source.
If you use internal certificate objects to configure captive portal, the system can authenticate the identity of
your captive portal device when connecting to users' web browsers.
If you use trusted certificate authority objects to configure realms, you can configure secure connections to
LDAP or AD servers.

Firepower Management Center Configuration Guide, Version 6.3

415
 Deployment Management
Internal Certificate Authority Objects

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
852.

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:

• 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

Firepower Management Center Configuration Guide, Version 6.3

416
 Deployment Management
CA Certificate and Private Key Import

• 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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except NGIPSv Any Admin/Access

Admin/Network
Admin

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 1 Choose Objects > Object Management.

Step 2 Expand the PKI node, and choose Internal CAs.
Step 3 Click Import CA.

Firepower Management Center Configuration Guide, Version 6.3

417
 Deployment Management
Generating a New CA Certificate and Private Key

Step 4 Enter a Name.

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

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

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

Generating a New CA Certificate and Private Key

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except NGIPSv Any Admin/Access

Admin/Network
Admin

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

Procedure

Step 1 Choose Objects > Object Management.

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

Step 5 Enter the identification attributes.

Step 6 Click Generate self-signed CA.

Firepower Management Center Configuration Guide, Version 6.3

418
 Deployment Management
New Signed Certificates

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except NGIPSv Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

Step 5 Enter the identification attributes.

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

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

Uploading a Signed Certificate Issued in Response to a CSR

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except NGIPSv Any Admin/Access

Admin/Network
Admin

Firepower Management Center Configuration Guide, Version 6.3

419
 Deployment Management
CA Certificate and Private Key Downloads

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

Procedure

Step 1 Choose Objects > Object Management.

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

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

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

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.

Firepower Management Center Configuration Guide, Version 6.3

420
 Deployment Management
Downloading a CA Certificate and Private Key

Downloading a CA Certificate and Private Key

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except NGIPSv Any Admin/Access

Admin/Network
Admin

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

Procedure

Step 1 Choose Objects > Object Management.

Step 2 Expand the PKI node, and choose Internal CAs.
Step 3 Next to the internal CA object whose certificate and private key you want to download, click the edit icon
( ).

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

Step 4 Click Download.

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

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.

Firepower Management Center Configuration Guide, Version 6.3

421
 Deployment Management
Trusted CA Object

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

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

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

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

Adding a Trusted CA Object

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except NGIPSv Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

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.

Firepower Management Center Configuration Guide, Version 6.3

422
 Deployment Management
Certificate Revocation Lists in Trusted CA Objects

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

Certificate Revocation Lists in Trusted CA Objects

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

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

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

Adding a Certificate Revocation List to a Trusted CA Object

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except NGIPSv Any Admin/Access

Admin/Network
Admin

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

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

Procedure

Step 1 Choose Objects > Object Management.

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

Step 3 Click the edit icon ( ) next to a trusted CA object.

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

Firepower Management Center Configuration Guide, Version 6.3

423
 Deployment Management
External Certificate Objects

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

Step 5 Click OK.

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

External Certificate Objects

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

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

Adding External Certificate Objects

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except NGIPSv Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

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

Firepower Management Center Configuration Guide, Version 6.3

424
 Deployment Management
Internal Certificate Objects

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

Internal Certificate Objects

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

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

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

Adding Internal Certificate Objects

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except NGIPSv Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

Step 2 Expand the PKI node, and choose Internal Certs.
Step 3 Click Add Internal Cert.

Firepower Management Center Configuration Guide, Version 6.3

425
 Deployment Management
Certificate Enrollment Objects

Step 4 Enter a Name.

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

Step 5 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
852.

How to Use Certificate Enrollment Objects

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

Managing Certificate Enrollment Objects

To manage certificate enrollment objects, go to Objects > Object Management, then from the navigation
pane choose PKI > Cert Enrollment. The following information is shown:
• Existing certificate enrollment objects are listed in the Name column.
Use the search field (the magnifying glass) to filter the list.

Firepower Management Center Configuration Guide, Version 6.3

426
 Deployment Management
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.
• 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 368 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 427. Then install the certificate on
each managed, headend device.
Related Topics
Installing a Certificate Using Self-Signed Enrollment , on page 465
Installing a Certificate Using SCEP Enrollment, on page 466
Installing a Certificate Using Manual Enrollment, on page 467
Installing a Certificate Using a PKCS12 File, on page 468

Adding Certificate Enrollment Objects

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Admin/Network

Admin

Procedure

Step 1 Open the Add Cert Enrollment dialog:

• Directly from Object Management: In the Objects > Object Management screen, choose PKI > Cert
Enrollment from the navigation pane, and press Add Cert Enrollment.

Firepower Management Center Configuration Guide, Version 6.3

427
 Deployment Management
Adding Certificate Enrollment Objects

• While configuring a managed device: In the Devices > Certificatesscreen, choose Add > Add New
Certificate and click (+) for the Certificate Enrollment field.

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

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

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

Step 4 (Optional) Open the Certificate Parameters tab and specify the certificate contents. See Certificate Enrollment
Object Certificate Parameters, on page 429.
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 430.
Step 6 (Optional) Click the Revocation tab, and specify the revocation options: See Certificate Enrollment Object
Revocation Options, on page 431.
Step 7 Allow Overrides of this object if desired. See Object Overrides, on page 368 for a full description of object
overrides.

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

Firepower Management Center Configuration Guide, Version 6.3

428
 Deployment Management
Certificate Enrollment Object SCEP Options

Certificate Enrollment Object SCEP Options

Firepower Management Center Navigation Path

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

Fields
Enrollment Type—set to SCEP.
Enrollment URL—The URL of the CA server to which devices should attempt to enroll.
Use an HTTP URL in the form of 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.

Firepower Management Center Configuration Guide, Version 6.3

429
 Deployment Management
Certificate Enrollment Object Key Options

Firepower Management Center Navigation Path

Objects > Object Management, then from the navigation pane choose PKI > PKI Enrollment. Press (+)
Add PKI Enrollment to open the Add PKI Enrollment dialog, and select the 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

Firepower Management Center Navigation Path

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

Fields
• Key Type—RSA (default, and only supported option) or ECDSA.

Firepower Management Center Configuration Guide, Version 6.3

430
 Deployment Management
Certificate Enrollment Object Revocation Options

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

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.

Firepower Management Center Navigation Path

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

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

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

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

DNS Server Group Objects

Domain Name System (DNS) servers resolve fully-qualified domain names (FQDN), such as
www.example.com, to IP addresses.

Firepower Management Center Configuration Guide, Version 6.3

431
 Deployment Management
Creating DNS Server Group Objects

Creating DNS Server Group Objects

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except NGIPS Any Access Admin/

Admin/ Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

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

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

Step 7 Enter the DNS Servers that will be a part of this group, either in IPv4 or IPv6 format as comma separated
entries.
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 1093.

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

Firepower Management Center Configuration Guide, Version 6.3

432
Deployment Management
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.

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

433
 Deployment Management
Prefix Lists

Step 11 Enter the number of packets that are sent in the Number of Packets field. Values range from 1 to 100. The
default is 1 packet.
Note Increase the default number of packets if you are concerned that packet loss might falsely cause the
Firepower Threat Defense device to believe that the monitored address cannot be reached.

Step 12 Enter the IP address that is being monitored for availability by the SLA operation, in the Monitored Address
field.
Step 13 The Available Zones list displays both zones and interface groups. In the Zones/Interfaces list, add the zones
or interface groups that contain the interfaces through which the device communicates with the management
station. To specify a single interface, you need to create a zone or the interface groups for the interface; see
Creating Security Zone and Interface Group Objects, on page 380. 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.

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

434
 Deployment Management
Configure IPv4 Prefix List

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

Configure IPv4 Prefix List

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

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Access Admin
Administrator
Network Admin

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 11 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object
Overrides, on page 369.

Firepower Management Center Configuration Guide, Version 6.3

435
 Deployment Management
Route Maps

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.

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

436
Deployment Management
Route Maps

• IPv4 — Match IPv4 (routes/traffic) based on the following criteria; select the tab to define the criteria.
1. 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.
2. 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.
3. 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.
1. 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.
2. 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.
3. 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.

1. 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.
2. 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.
3. 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.
1. 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.
2. 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.

Firepower Management Center Configuration Guide, Version 6.3

437
 Deployment Management
Route Maps

3. Enter the EIGRP route delay in tens of microseconds in the Delay field. Valid values range from
1to 4294967295.
4. Enter the likelihood of successful packet transmission for EIGRP in the Reliability field. Valid values
range from 0 to 255. The value 255 means 100 percent reliability; 0 means no reliability.
5. Enter the effective EIGRP bandwidth of a route in the Effective field. Valid values range from 1 to
255. The value 255 means 100 percent loading.
6. Enter the minimum MTU size of a route for EIGRP, in bytes in the MTU field. Valid values range
from 1 to 4294967295.

• BGP Clauses — Set BGP routes based on the following criteria; select the tab to define the criteria.
1. 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.

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

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

3. 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.

Firepower Management Center Configuration Guide, Version 6.3

438
 Deployment Management
Access List

6. In the IPv6 Settings section, specify a next hop IPv6 address of the next hop to which packets
are output. It need not be an adjacent router. If you specify more than one IPv6 address then the
packets can output at either IP address.
Select to specify an IPv6 prefix in the Prefix List drop-down list.

Step 8 Click Add.

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

Access List
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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. Traffic identified as
allowed by the ACL is provided the service, whereas “blocked” traffic is excluded from the service. Excluding
traffic from a service does not necessarily mean that it is dropped altogether.
You can configure the following types of ACL:
• Extended—Identifies traffic based on source and destination address and ports. Supports IPv4 and IPv6
addresses, which you can mix in a given rule.
• Standard—Identifies traffic based on destination address only. Supports IPv4 only.

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

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.

Firepower Management Center Configuration Guide, Version 6.3

439
 Deployment Management
Configure Extended ACL Objects

Procedure

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

• Click the edit icon ( ) 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 the edit icon ( ) 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.
• Select the desired port 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. 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.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

440
 Deployment Management
Configure Standard ACL Objects

Step 4 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object
Overrides, on page 369.
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.
Step 2 Do one of the following:
• Click Add Standard ACL to create a new object.

• Click the edit icon ( ) to edit an existing object.

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

• Click the edit icon ( ) 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.

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

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

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

Firepower Management Center Configuration Guide, Version 6.3

441
 Deployment Management
AS Path Objects

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.

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Access Admin
Administrator
Network Admin

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 5 If you want to allow overrides for this object, check the Allow Overrides check box; see Allowing Object
Overrides, on page 369.
Step 6 Click Save.

Community Lists
A Community is an optional transitive BGP attribute. A community is a group of destinations that share some
common attribute. It is used for route tagging. The BGP community attribute is a numerical value that can be
assigned to a specific prefix and advertised to other neighbors. Communities can be used to mark a set of
prefixes that share a common attribute. Upstream providers can use these markers to apply a common routing
policy such as filtering or assigning a specific local preference or modifying other attributes. Use the Configure
Community Lists page to create, copy and edit community list policy objects. You can create community list
objects to use when you are configuring route maps or policy maps. You can use community lists to create

Firepower Management Center Configuration Guide, Version 6.3

442
Deployment Management
Community Lists

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.

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Access Admin
Administrator
Network Admin

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.
a) Select the Allow or Block options from the Action drop-down list to indicate redistribution access.
b) In the Communities field, specify a community number. Valid values can be from 1 to 4294967295 or
from 0:1 to 65534:65535.
c) Select the appropriate Route Type.
• Internet — Select to specify the Internet well-known community. Routes with this community are
advertised to all peers (internal and external).
• No Advertise — Select to specify the no-advertise well-known community. Routes with this
community are not advertised to any peer (internal or external).
• No Export — Select to specify the no-export well-known community. Routes with this community
are advertised to only peers in the same autonomous system or to only other sub-autonomous systems
within a confederation. These routes are not advertised to external peers.

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

Firepower Management Center Configuration Guide, Version 6.3

443
 Deployment Management
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.

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Access Admin
Administrator
Network Admin

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.
Choose whether to use an Access List or Prefix List for matching and then enter or select the Standard Access
List Objects or Prefix list objects you want to use for matching.

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

Step 9 Click the AS Path tab to match a BGP autonomous system path. If you specify more than one AS path, then
the route can match either AS path.
Step 10 Click the Community Rule tab to enable matching the BGP community with the specified community. If
you specify more than one community, then the route can match either community. To enable matching the

Firepower Management Center Configuration Guide, Version 6.3

444
 Deployment Management
VPN Objects

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

VPN Objects
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 843.

Configure IKEv1 Policy Objects

Smart License Classic License Supported Devices Supported Domains Access

Export-Compliance N/A FTD Leaf only Admin

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

Firepower Management Center Configuration Guide, Version 6.3

445
 Deployment Management
Configure IKEv1 Policy Objects

Procedure

Step 1 Choose Objects > Object Management and then VPN > IKEv1 Policy from the table of contents.
Previously configured policies are listed including system defined defaults. Depending on your level of access,
you may Edit ( ), View ( ), or Delete ( ) a proposal.

Step 2 (Optional) Choose 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 849.

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 850.

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 850.

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.

Firepower Management Center Configuration Guide, Version 6.3

446
 Deployment Management
Configure IKEv2 Policy Objects

• Certificate—When you use Certificates as the authentication method for VPN connections, peers obtain
digital certificates from a CA server in your PKI infrastructure, and trade them to authenticate each other.

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

Step 11 Click Save

The new IKEv1 policy is added to the list.

Configure IKEv2 Policy Objects

Smart License Classic License Supported Devices Supported Domains Access

Export-Compliance N/A FTD Leaf only Admin

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 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.

Firepower Management Center Configuration Guide, Version 6.3

447
 Deployment Management
FTD IPsec Proposals

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

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

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 850.

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 850.

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.

Firepower Management Center Configuration Guide, Version 6.3

448
 Deployment Management
Configure IKEv1 IPsec Proposal Objects

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

Configure IKEv1 IPsec Proposal Objects

Smart License Classic License Supported Devices Supported Domains Access

Export-Compliance N/A FTD Leaf only Admin

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 ( ), or Delete ( ) a Proposal.

Step 2 Choose Add IPsec IKEv1 Proposal to create a new Proposal.

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

Step 4 Enter a Description for this Proposal.

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

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

Step 6 Select an option for ESP Hash.

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

Step 7 Click Save

The new Proposal is added to the list.

Configure IKEv2 IPsec Proposal Objects

Smart License Classic License Supported Devices Supported Domains Access

Export-Compliance N/A FTD Leaf only Admin

Firepower Management Center Configuration Guide, Version 6.3

449
 Deployment Management
FTD Group Policy Objects

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 ( ), View ( ), or Delete ( ) a Proposal.

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

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

Step 4 Enter a Description for this Proposal.

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

Step 5 Choose the ESP Hash method, the hash or integrity algorithm to use in the Proposal for authentication.
For IKEv2, select all the options you want to support for ESP Hash. For a full explanation of the options,
see Deciding Which Hash Algorithms to Use, on page 850.

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 849.

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.

Related Topics
Configure Group Policy Objects, on page 451

Firepower Management Center Configuration Guide, Version 6.3

450
 Deployment Management
Configure Group Policy Objects

Configure Group Policy Objects

Smart License Classic License Supported Devices Supported Domains Access

One of these AnyConnect N/A FTD Any Administrator

licenses associated with
your Smart License
account with Export
Controlled Features
enabled:
• AnyConnect VPN
Only
• AnyConnect Plus
• AnyConnect Apex

See FTD Group Policy Objects, on page 450.

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
452.
Step 5 Specify the AnyConnect parameters for this Group Policy as described in Group Policy AnyConnect Options,
on page 453.
Step 6 Specify the Advanced parameters for this Group Policy as described in Group Policy Advanced Options, on
page 455.
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.
Related Topics
Adding and Editing Remote Access VPN Connection Profiles

Firepower Management Center Configuration Guide, Version 6.3

451
 Deployment Management
Group Policy General Options

Group Policy General Options

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

VPN Protocols Fields

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

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

Firepower Management Center Configuration Guide, Version 6.3

452
 Deployment Management
Group Policy AnyConnect Options

only partial HTML. To ensure that the banner displays properly to remote users, use the /n tag for IPsec clients,
and the <BR> tag for SSL clients.

DNS/WINS Fields
Domain Naming System (DNS) and Windows Internet Naming System (WINS) servers. Used for AnyConnect
client name resolution.
• Primary DNS Server and Secondary DNS Server—Choose or create a Network Object which defines
the IPv4 or IPv6 addresses of the DNS servers you want this group to use.
• Primary WINS Server and Secondary WINS Server—Choose or create a Network Object containing
the IP addresses of the WINS servers you want this group to use.
• DHCP Network Scope—Choose or create a Network Object containing the IPv4 address of the DHCP
Network for this group. This setting does not support IPv6, address ranges, or subnet specifications. If
not set properly, deployment of the VPN policy fails.
• Default Domain—Name of the default domain. Specify a top-level domain, for example, example.com.

Split 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 439 for details.
• DNS Request Split Tunneling—Also known as Split DNS. Configure the DNS behaviour expected in
your environment.
By default, split DNS is not enabled and set to Send DNS request as per split tunnel policy. Choosing
Always send DNS request over tunnel forces all DNS requests to be sent over the tunnel to the private
network.
To configure split DNS, choose Send only specified domains over tunnel, and enter the list of domain
names in the Domain List field. These requests are resolved through the split tunnel to the private
network. All other names are resolved using the public DNS server. Enter up to ten entries in the list of
domains, separated by commas. The entire string can be no longer than 255 characters.

Related Topics
Configure Group Policy Objects, on page 451

Group Policy AnyConnect Options

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

Firepower Management Center Configuration Guide, Version 6.3

453
 Deployment Management
Group Policy AnyConnect Options

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

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

Firepower Management Center Configuration Guide, Version 6.3

454
 Deployment Management
Group Policy Advanced Options

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

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

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

Related Topics
Configure Group Policy Objects, on page 451

Group Policy Advanced Options

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

Traffic Filter Fields

• Access List Filter—Filters consist of rules that determine whether to allow or block tunneled data packets
coming through the VPN connection. Rules are based on criteria such as source address, destination
address, and protocol. 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.

Firepower Management Center Configuration Guide, Version 6.3

455
 Deployment Management
FTD File Objects

• 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 381 for details.
• Simultaneous Logins Per User—Specifies the maximum number of simultaneous logins allowed for
a user. The default value is 3. The minimum value is 0, which disables login and prevents user access.
Allowing several simultaneous connections may compromise security and affect performance.
• Maximum Connection Time / Alert Interval—Specifies the maximum user connection time in minutes.
At the end of this time, the system stops the connection. The minimum is 1 minute). The Alert interval
specifies the interval of time before maximum connection time is reached to display a message to the
user.
• Idle Timeout / Alert Interval—Specifies this user’s idle timeout period in minutes. If there is no
communication activity on the user connection in this period, the system stops the connection. The
minimum time is 1 minute. The default is 30 minutes. The Alert interval specifies the interval of time
before idle time is reached to display a message to the user.

Related Topics
Configure Group Policy Objects, on page 451

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.
When you create a file object, the Firepower Management Center makes a copy of the file in its repository.
These files are backed up whenever you create a backup of the database, and they are restored if you restore
the database. When copying a file to the Firepower Management Center platform to be used in a file object,
do not copy the file directly to the file repository.
When you delete a file object, the associated file is not deleted from the file repository, only the object is
deleted.
When you deploy configurations that specify a file object, the associated file is download to the device in the
appropriate directory.

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

Firepower Management Center Configuration Guide, Version 6.3

456
 Deployment Management
FTD Certificate Map Objects

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

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

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

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.

Firepower Management Center Configuration Guide, Version 6.3

457
 Deployment Management
Address Pools

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

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.

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Access Admin
Administrator
Network Admin

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.
• 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 368
for more information.

Step 3 Click Save.

Step 4 Click Add IPv6 Pools, and configure the following fields:
• Name—Enter the name of the address pool. It can be up to 64 characters
• Description—Add an optional description for this pool.
• IPv6 Address—Enter the first IP address available in the configured pool and the prefix length in bits.
For example: 2001:DB8::1/64.
• Number of Addresses—Identifies the number of IPv6 addresses, starting at the Starting IP Address,
that are in the pool.

Firepower Management Center Configuration Guide, Version 6.3

458
 Deployment Management
FlexConfig Objects

• 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 368 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 953.
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 979.
FlexConfig Objects
FlexConfig Objects include device configuration commands, variables, and scripting language instructions.
During configuration deployment, these instructions are processed to create a sequence of configuration
commands with customized parameters to configure specific features on the target devices.
These instructions are either configured before (prepended) the system configures features defined in
regular Firepower Management Center policies and settings, or after (appended). Any FlexConfig that
depends on Firepower Management Center-configured objects (for example, a network object) must be
appended to the configuration deployment, or the needed objects would not be configured before the
FlexConfig needed to refer to the objects.
For more information on configuring FlexConfig objects, see Configure FlexConfig Objects, on page
975.

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.

Firepower Management Center Configuration Guide, Version 6.3

459
 Deployment Management
RADIUS Server Group Options

Before you begin

Note You cannot override RADIUS Server Group Objects.

Procedure

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

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

Step 3 Click Save

RADIUS Server Group Options

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

Fields
• Name and Description—Enter a name and optionally, a description to identify this RADIUS Server
Group object.
• Group Accounting Mode—The method for sending accounting messages to the RADIUS servers in
the group. Choose Single, accounting messages are sent to a single server in the group, this is the default.
Or, Simultaneous, accounting messages are sent to all servers in the group simultaneously.
• Retry Interval—The interval between attempts to contact the RADIUS servers. Values range from 1 to
10 seconds.
• Realms(Optional)—Specify or select the AD or LDAP 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.

Firepower Management Center Configuration Guide, Version 6.3

460
 Deployment Management
RADIUS Server Options

• 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 461.

Related Topics
RADIUS Server Groups, on page 459

RADIUS Server Options

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

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

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

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

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

Firepower Management Center Configuration Guide, Version 6.3

461
 Deployment Management
RADIUS Server Options

• Connect Using —Establishes connectivity from Firepower Threat Defense to RADIUS server is done
using routing or specific interface. Select Routing for the RADIUS server connectivity is established by
a path resolved by routing table. Or select Specific Interface and choose an interface from the list or
add a new interface/security zone.
Firepower Threat Defense to RADIUS server connectivity is established via a specified interface, which
is part of a security zone or an interface group. If no interface is selected from the list, diagnostic interface
is used as the default interface.
See Interface Objects: Interface Groups and Security Zones, on page 379.
• Redirect ACL—Select the redirect ACL from the list or add a new one.

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

Related Topics
RADIUS Server Groups, on page 459
RADIUS Server Group Options, on page 460

Firepower Management Center Configuration Guide, Version 6.3

462
 CHAPTER 19
Firepower Threat Defense Certificate-Based
Authentication
• Firepower Threat Defense VPN Certificate Guidelines and Limitations, on page 463
• Managing FTD Certificates, on page 464
• Installing a Certificate Using Self-Signed Enrollment , on page 465
• Installing a Certificate Using SCEP Enrollment, on page 466
• Installing a Certificate Using Manual Enrollment, on page 467
• Installing a Certificate Using a PKCS12 File, on page 468
• Troubleshooting FTD Certificates, on page 468

Firepower Threat Defense VPN Certificate Guidelines and

Limitations
• When a certificate enrollment objectPKI 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.
• 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 VPN Authentication Method.
• The FTD devices support, and have verified certificate enrollment using: Microsoft CA Service, and CA
Services provided on Cisco Adaptive Security Appliances and Cisco IOS Router.
• The FTD devices cannot be configured as a 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 the parent domain, the certificate enrollment object also needs to be in
that domain. If the trustpoint on the device is overridden in the child domain, the overridden value will
be deployed on the device.
• When 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.

Firepower Management Center Configuration Guide, Version 6.3

463
 Deployment Management
Managing FTD Certificates

• When a leaf domain is deleted, certificate enrollments on 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

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Admin/Network

Admin/Security
Approver

See PKI Infrastructure and Digital Certificates , on page 852 for an introduction to Digital Certificates.
See Certificate Enrollment Objects, on page 426 for a description of the objects used to enroll and obtain
certificates on managed devices.

Procedure

Step 1 Go to Devices > Certificates.

On this screen:
• Devices that already have trustpoints associated with them will be listed under the Name column. Expand
the device to see the list of associated trustpoints.
The type of enrollment used for this trustpoint is displayed under the Enrollment Type column.
Certificates that are enrolled in a specific domain are displayed under the Domain column.
• The Status column provides the status of the CA Certificate and Identity Certificate. The certificate
contents, when Available, can be viewed by clicking the magnifying glass.
If the enrollment fails, click the icon to view the failure message.

• Refresh (circling arrows) a certificate on a managed device. Refreshing a certificate would synchronize
the Firepower Threat Defense device certificate status to the Firepower Management Center.
• Using the re-enroll icon, enroll the identity certificate.
During the course of any policy deployment, if the certificate enrollment process fails, enroll the identity
certificate again using the re-enroll option.
• Delete (trash can) a configured certificate.

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

Firepower Management Center Configuration Guide, Version 6.3

464
 Deployment Management
Installing a Certificate Using Self-Signed Enrollment

it does not require any additional administrator action. Manual certificate enrollment requires extra administrator
action.
Note The certificate enrollment on a device does not block the user interface and the enrollment process
gets executed in the background, enabling the user to perform certificate enrollment on other devices
in parallel. The progress of these parallel operations can be monitored on the same user interface.
The respective icons display the certificate enrollment status.

Related Topics
Installing a Certificate Using Self-Signed Enrollment , on page 465
Installing a Certificate Using SCEP Enrollment, on page 466
Installing a Certificate Using Manual Enrollment, on page 467
Installing a Certificate Using a PKCS12 File, on page 468

Installing a Certificate Using Self-Signed Enrollment

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Admin/Network

Admin

Procedure

Step 1 On the Devices > Certificatesscreen, 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 427.

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 an an icon,
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.

Firepower Management Center Configuration Guide, Version 6.3

465
 Deployment Management
Installing a Certificate Using SCEP Enrollment

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

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Admin/Network

Admin

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

Step 1 On the Devices > Certificates screen, choose Add to open the Add New Certificate dialog.
Step 2 Choose a device from the Device drop-down list.
Step 3 Associate a certificate enrollment object with this device in one of the following ways:
• Choose a Certificate Enrollment Object of the type SCEP from the drop-down list.
• Click (+) icon, to add a new Certificate Enrollment Object, see Adding Certificate Enrollment Objects,
on page 427.

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

Firepower Management Center Configuration Guide, Version 6.3

466
 Deployment Management
Installing a Certificate Using Manual Enrollment

Installing a Certificate Using Manual Enrollment

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Admin/Network

Admin

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 Manual from the drop-down list.
• Click (+) icon, to add a new Certificate Enrollment Object, see Adding Certificate Enrollment Objects,
on page 427.

Step 4 Press Add to start the enrollment process.

Step 5
Step 6 Execute the appropriate activity with your PKI CA Server to obtain an identity certificate.
a) Click the Identity Certificate warning icon 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 7 Select Import to import the Identity Certificate.

The Identity Certificate status will be Available when the import complete.

Step 8 Click the magnifying glass to view the Identity Certificate for this device.

What to do next
When enrollment is complete, a trustpoint exists on the device with the same name as the certificate enrollment
object. Use this trustpoint in the configuration of your Site to Site and Remote Access VPN Authentication
Method

Firepower Management Center Configuration Guide, Version 6.3

467
 Deployment Management
Installing a Certificate Using a PKCS12 File

Installing a Certificate Using a PKCS12 File

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Admin/Network

Admin

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.
Step 3 Associate a certificate enrollment object with this device in one of the following ways:
• Choose a Certificate Enrollment Object of the PKCS type from the drop-down list.
• Click (+) icon, to add a new Certificate Enrollment Object, see Adding Certificate Enrollment Objects,
on page 427.

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

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Admin/Network

Admin/Security
Approver

See Firepower Threat Defense VPN Certificate Guidelines and Limitations, on page 463 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.

Firepower Management Center Configuration Guide, Version 6.3

468
Deployment Management
Troubleshooting FTD Certificates

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 the Extensions Tab > Application policies, select IP security end system, instead of the IP security
IKE intermediate.
3. Set the permissions and the template name.
4. Add the new template and change the registry settings to reflect the new template name.

Firepower Management Center Configuration Guide, Version 6.3

469
 Deployment Management
Troubleshooting FTD Certificates

Firepower Management Center Configuration Guide, Version 6.3

470
PA R T V
Appliance Management Basics
• Firepower Management Center Basics, on page 473
• Firepower Management Center High Availability, on page 477
• Device Management Basics, on page 497
 CHAPTER 20
Firepower Management Center Basics
The following topics describe Firepower Management Center basics:
• The Firepower Management Center, on page 473
• Device Management, on page 473
• NAT Environments, on page 475

The Firepower Management Center

You can use the Firepower Management Center to manage the full range of devices that are a part of the
Firepower System. When you manage a device, you set up a two-way, SSL-encrypted communication channel
between the Firepower Management Center 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.

Device Management
The Firepower Management Center is a key component in the Firepower System. You can use the Firepower
Management Center to manage the full range of devices that comprise the Firepower System, and to aggregate,
analyze, and respond to the threats they detect on your network.
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.
You can use a Firepower Management Center to manage nearly every aspect of a device’s behavior.

Firepower Management Center Configuration Guide, Version 6.3

473
 Appliance Management Basics
What Can Be Managed by a Firepower Management Center?

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:
• 7000 and 8000 Series devices
• ASA FirePOWER modules
• NGIPSv devices
• Firepower Threat Defense and Firepower Threat Defense 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.

Firepower Management Center Configuration Guide, Version 6.3

474
 Appliance Management Basics
NAT Environments

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.
Related Topics
Backup Files, on page 165

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 (see Add Devices to the
Firepower Management Center, on page 499), and the device specifies the FMC IP address (see the getting
started guide for your model; or see Management Interfaces, on page 1006 to change settings after initial setup).
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.

Firepower Management Center Configuration Guide, Version 6.3

475
 Appliance Management Basics
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

Firepower Management Center Configuration Guide, Version 6.3

476
 CHAPTER 21
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 477
• Establishing Firepower Management Center High Availability, on page 483
• Viewing Firepower Management Center High Availability Status, on page 485
• Configurations Synced on Firepower Management Center High Availability Pairs, on page 486
• Using CLI to Resolve Device Registration in Firepower Management Center High Availability, on page
487
• Switching Peers in a Firepower Management Center High Availability Pair, on page 487
• Pausing Communication Between Paired Firepower Management Centers, on page 488
• Restarting Communication Between Paired Firepower Management Centers, on page 489
• Changing the IP address of a Firepower Management Center in a High Availability Pair, on page 489
• Disabling Firepower Management Center High Availability, on page 490
• Replacing Firepower Management Centers in a High Availability Pair, on page 491

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.
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.

Firepower Management Center Configuration Guide, Version 6.3

477
 Appliance Management Basics
System Requirements Firepower Management Center High Availability

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.

System Requirements Firepower Management Center High Availability

This section describes the hardware, software, and license requirements for Firepower Management Centers
in a high availability configuration.

Hardware Requirements
• The two Firepower Management Centers in a high availability configuration must be the same model.
• The primary Firepower Management Center backup must not be restored to the secondary Firepower
Management Center.
• Bandwidth Requirements: There must be atleast a 5Mbps network bandwidth between two Firepower
Management Centers to setup a high availability configuration between them.

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 220
• The two Firepower Management Centers in a high availability configuration must have the same major
(first number), minor (second number), and maintenance (third number) software version.
• The two Firepower Management Centers in a high availability configuration must have the same version
of the intrusion rule update installed.
• The two Firepower Management Centers in a high availability configuration must have the same version
of the vulnerability database update installed.

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.

Firepower Management Center Configuration Guide, Version 6.3

478
 Appliance Management Basics
License Requirements

License Requirements

All Licensing Types

No special license is required for Firepower Management Center appliances in a high availability pair.
A device managed with Firepower Management Center 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.
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.

Smart Licensing
Example: If you want to enable advanced malware protection for two Firepower Threat Defense devices
managed by a Firepower Management Center pair, buy two Malware licenses and two TM subscriptions,
register the active Firepower Management Center with the Cisco Smart Software Manager, then assign the
licenses to the two Firepower Threat Defense devices on the active Firepower Management Center.
Only the active Firepower Management Center is registered with Cisco Smart Software Manager. When
failover occurs, the system communicates with Cisco Smart Software Manager to release the Smart License
entitlements from the originally-active Firepower Management Center and assign them to the newly-active
Firepower Management Center.

Classic Licensing
Example: If you want to enable advanced malware protection for two devices managed by a Firepower
Management Center pair, buy two Malware licenses and two TAM subscriptions, add those licenses to the
Firepower Management Center, then assign the licenses to the two devices on the active Firepower Management
Center.

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.

Firepower Management Center Configuration Guide, Version 6.3

479
 Appliance Management Basics
Prerequisites to Establish Firepower Management Center High Availability

Prerequisites to Establish 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
189.
• 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 Deleting
Devices from the Firepower Management Center, on page 501 and Add Devices to the Firepower
Management Center, on page 499.
• Import the policies into the intended primary Firepower Management Center. For more information, see
Importing Configurations, on page 190.
• 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 308.
• 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 129.
• Note that any existing configurations on the intended secondary Firepower Management Center for
integrations with Cisco Security Packet Analyzer will be overwritten when synchronization occurs. If
necessary, recreate any such configurations on the intended primary Firepower Management Center.

You can now proceed to establish high availability. For more information, see Establishing Firepower
Management Center High Availability, on page 483.

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

480
 Appliance Management Basics
User Data Processing During Firepower Management Center Failover

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, all logins reported by a User Agent, ISE/ISE-PIC, TS
Agent, or captive portal device cannot be identified during failover downtime, even if the users were previously
seen and downloaded to the Firepower Management Center. The unidentified users are logged as Unknown
users on the Firepower Management Center.
After the downtime, the Unknown users are reidentified 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 1602.

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.

Firepower Management Center Configuration Guide, Version 6.3

481
 Appliance Management Basics
Upgrading Firepower Management Centers in a High Availability Pair

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.

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 488.
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.

Firepower Management Center Configuration Guide, Version 6.3

482
 Appliance Management Basics
Troubleshooting Firepower Management Center High Availability

Troubleshooting Firepower Management Center High Availability

This section lists troubleshooting information for some common Firepower Management Center high availability
operation errors.

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.

Establishing Firepower Management Center High Availability

Smart License Classic License Supported Supported Domains Access
Management
Centers

Any Any MC1000, MC1500, Global Admin

MC2000, MC2500,
MC3500, MC4000,
MC4500

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.

Firepower Management Center Configuration Guide, Version 6.3

483
 Appliance Management Basics
Establishing Firepower Management Center High Availability

Before you begin

• Confirm that both the Firepower Management Centers adhere to the high availability system requirements.
For more information , see System Requirements Firepower Management Center High Availability , on
page 478.
• Confirm that you completed the prerequisites for establishing high availability. For more information,
see Prerequisites to Establish Firepower Management Center High Availability, on page 480.

Procedure

Step 1 Log into the Firepower Management Center that you want to designate as the secondary.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Under Role for this Firepower Management Center, choose Secondary.
Step 5 Enter the hostname or IP address of the primary Firepower Management Center in the Primary Firepower
Management Center Host text box.
You can leave this empty if the primary Firepower Management Center does not have a routable address. In
this case, use both the Registration Key and the Unique NAT ID fields. You also need to specify the secondary
IP address on the primary unit; you need to specify the IP address of at least one unit.

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 475 for more information.
Step 8 Click Register.
Step 9 Using an account with Admin access, log into the Firepower Management Center that you want to designate
as the primary.
Step 10 Choose System > Integration.
Step 11 Choose High Availability.
Step 12 Under Role for this Firepower Management Center, choose Primary.
Step 13 Enter the hostname or IP address of the secondary Firepower Management Center in the Secondary Firepower
Management Center Host text box.
You can leave this empty if the secondary Firepower Management Center does not have a routable address.
In this case, use both the Registration Key and the Unique NAT ID fields. You also need to specify the
primary IP address on the secondary unit; you need to specify the IP address of at least one unit.

Step 14 Enter the same one-time-use registration key in the Registration Key text box you used in step 6.
Step 15 If required, enter the same NAT ID that you used in step 7 in the Unique NAT ID text box.
Step 16 Click Register.

Firepower Management Center Configuration Guide, Version 6.3

484
 Appliance Management Basics
Viewing Firepower Management Center High Availability Status

What to do next
After establishing a Firepower Management Center high availability pair, devices registered to the active
Firepower Management Center are automatically registered to the standby Firepower Management Center.

Note When a registered device has a NAT IP address, automatic device registration fails and the secondary Firepower
Management Center High Availablity page lists the device as local, pending. You can then assign a different
NAT IP address to the device on the standby Firepower Management Center High Availability page. If
automatic registration otherwise fails on the standby Firepower Management Center, but the device appears
to be registered to the active Firepower Management Center, see Using CLI to Resolve Device Registration
in Firepower Management Center High Availability, on page 487.

ViewingFirepowerManagementCenterHighAvailabilityStatus
Smart License Classic License Supported Supported Domains Access
Management
Centers

Any Any MC1000, MC1500, Global Admin

MC2000, MC2500,
MC3500, MC4000,
MC4500

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.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
You can view:
Summary Information
• The health status of the high availability pair
• The current synchronization status of the high availability pair
• The IP address of the active peer and the last time it was synchronized
• The IP address of the standby peer and the last time it was synchronized

Firepower Management Center Configuration Guide, Version 6.3

485
 Appliance Management Basics
Configurations Synced on Firepower Management Center High Availability Pairs

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

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
• Integration with Cisco Security Packet Analyzer
• 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 2250.

Firepower Management Center Configuration Guide, Version 6.3

486
 Appliance Management Basics
Using CLI to Resolve Device Registration in Firepower Management Center High Availability

Using CLI to Resolve Device Registration in Firepower

Management Center High Availability
Smart License Classic License Supported Supported Domains Access
Management
Centers

Any Any MC1000, MC1500, Global Admin

MC2000, MC2500,
MC3500, MC4000,
MC4500

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:

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
Firepower Management Center.

Step 5 Log into the active Firepower Management Center and register the device.

Switching Peers in a Firepower Management Center High

Availability Pair
Smart License Classic License Supported Supported Domains Access
Management
Centers

Any Any MC1000, MC1500, Global Admin

MC2000, MC2500,
MC3500, MC4000,
MC4500

Firepower Management Center Configuration Guide, Version 6.3

487
 Appliance Management Basics
Pausing Communication Between Paired Firepower Management Centers

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

Step 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Choose Switch Peer Roles to change the local role from Active to Standby, or Standby to Active. With the
Primary or Secondary designation unchanged, the roles are switched between the two peers.

Pausing Communication Between Paired Firepower

Management Centers
Smart License Classic License Supported Supported Domains Access
Management
Centers

Any Any MC1000, MC1500, Global Admin

MC2000, MC2500,
MC3500, MC4000,
MC4500

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 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Choose Pause Synchronization.

Firepower Management Center Configuration Guide, Version 6.3

488
 Appliance Management Basics
Restarting Communication Between Paired Firepower Management Centers

Restarting Communication Between Paired Firepower

Management Centers
Smart License Classic License Supported Supported Domains Access
Management
Centers

Any Any MC1000, MC1500, Global Admin

MC2000, MC2500,
MC3500, MC4000,
MC4500

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 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Choose Resume Synchronization.

Changing the IP address of a Firepower Management Center in

a High Availability Pair
Smart License Classic License Supported Supported Domains Access
Management
Centers

Any Any MC1000, MC1500, Global Admin

MC2000, MC2500,
MC3500, MC4000,
MC4500

Note If you landed on this topic while trying to edit remote management on a 7000 and 8000 Series managed device,
see Editing Remote Management on a Managed Device, on page 524.

Firepower Management Center Configuration Guide, Version 6.3

489
 Appliance Management Basics
Disabling Firepower Management Center High Availability

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 1 Log into one of the Firepower Management Centers that you paired using high availability.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
Step 4 Choose Peer Manager.

Step 5 Choose the edit icon ( ).

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 Choose Save.

Disabling Firepower Management Center High Availability

Smart License Classic License Supported Supported Domains Access
Management
Centers

Any Any MC1000, MC1500, Global Admin

MC2000, MC2500,
MC3500, MC4000,
MC4500

Procedure

Step 1 Log into one of the Firepower Management Centers in the high availability pair.
Step 2 Choose System > Integration.
Step 3 Choose High Availability.
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.

Firepower Management Center Configuration Guide, Version 6.3

490
 Appliance Management Basics
Replacing Firepower Management Centers in a High Availability Pair

• To stop managing devices altogether, choose Stop managing registered devices from both consoles.
All devices will be unregistered from both Firepower Management Centers.

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 Smart
Licenses from Managed Devices, on page 117.

Step 6 Click OK.

ReplacingFirepowerManagementCentersinaHighAvailability
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 Firepower Management Data backup successful Replace a Failed Primary Firepower
Center failed Management Center (Successful
Backup), on page 491

Data backup not successful Replace a Failed Primary

Firepower Management Center
(Unsuccessful Backup), on page
493

Secondary Firepower Management Data backup successful Replace a Failed Secondary

Center failed Firepower Management Center
(Successful Backup), on page 494

Data backup not successful Replace a Failed Secondary

Firepower Management Center
(Unsuccessful Backup), on page
495

Replace a Failed Primary Firepower Management Center (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.

Firepower Management Center Configuration Guide, Version 6.3

491
 Appliance Management Basics
Replace a Failed Primary Firepower Management Center (Successful Backup)

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 487.
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.
Warning Do not break Firepower Management Center High Availability from FMC2, since classic and smart
licenses that were synced to FMC2 from FMC1 (before failure ), will be removed from FMC2 and
you will be unable to perform any deploy actions from FMC2.

Step 3 Reimage the replacement Firepower Management Center with the same software version as FMC1.
Step 4 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 487.
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 126.
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.

Firepower Management Center Configuration Guide, Version 6.3

492
 Appliance Management Basics
Replace a Failed Primary Firepower Management Center (Unsuccessful Backup)

Replace a Failed Primary Firepower Management Center (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 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 487.
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.
Warning Do not break Firepower Management Center High Availability from FMC2, since classic and smart
licenses that were synced to FMC2 from FMC1 (before failure ), will be removed from FMC2 and
you will be unable to perform any deploy actions from FMC2.

Step 3 Reimage the replacement Firepower Management Center with the same software version as FMC1.
Step 4 Install required Firepower Management Center patches, geolocation database (GeoDB) updates, vulnerability
database (VDB) updates and system software updates to match FMC2.
Step 5 Deregister the Firepower Management Center - FMC2 from the Cisco Smart Software Manager. For more
information, see Deregister a Firepower Management Center from the Cisco Smart Software Manager, on
page 118.
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 490. 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 483.
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 126.

Firepower Management Center Configuration Guide, Version 6.3

493
 Appliance Management Basics
Replace a Failed Secondary Firepower Management Center (Successful Backup)

Step 9 Register a Smart License to the primary Firepower Management Center - FMC2. For more information see
Register Smart Licenses, on page 95.

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 Secondary Firepower Management Center (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 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.

Procedure

Step 1 Contact Support to request a replacement for a failed Firepower Management Center - FMC2.
Step 2 Continue to use the primary Firepower Management Center - FMC1 as the active Firepower Management
Center.
Step 3 Reimage the replacement Firepower Management Center with the same software version as FMC2.
Step 4 Restore the data backup from FMC2 to the new Firepower Management Center.
Step 5 Install required Firepower Management Center patches, geolocation database (GeoDB) updates, vulnerability
database (VDB) updates and system software updates to match FMC1.
Step 6 Resume data synchronization (if paused) from the web interface of the new Firepower Management Center
- FMC2, to synchronize the latest configuration from the primary Firepower Management Center - FMC1.
For more information, see Restarting Communication Between Paired Firepower Management Centers, on
page 489.
Classic and Smart Licenses work seamlessly.

What to do next
High availability has now been re-established and the primary and the secondary Firepower Management
Centers will now work as expected.

Firepower Management Center Configuration Guide, Version 6.3

494
 Appliance Management Basics
Replace a Failed Secondary Firepower Management Center (Unsuccessful Backup)

Replace a Failed Secondary Firepower Management Center (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 secondary Firepower
Management Center -FMC2 when data backup from the secondary is unsuccessful.

Procedure

Step 1 Contact Support to request a replacement for a failed Firepower Management Center - FMC2.
Step 2 Continue to use the primary Firepower Management Center - FMC1 as the active Firepower Management
Center.
Step 3 Reimage the replacement Firepower Management Center with the same software version as FMC2.
Step 4 Install required Firepower Management Center patches, geolocation database (GeoDB) updates, vulnerability
database (VDB) updates and system software updates to match FMC1.
Step 5 Access the web interface of the primary Firepower Management Center - FMC1 and break Firepower
Management Center high availability. For more information, see Disabling Firepower Management Center
High Availability, on page 490. 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 483.
• When high availability is successfully established, the latest configuration from the primary Firepower
Management Center - FMC1 is synchronized to the secondary Firepower Management Center - FMC2.
• Classic and Smart Licenses work seamlessly.

What to do next
High availability has now been re-established and the primary and the secondary Firepower Management
Centers will now work as expected.

Firepower Management Center Configuration Guide, Version 6.3

495
 Appliance Management Basics
Replace a Failed Secondary Firepower Management Center (Unsuccessful Backup)

Firepower Management Center Configuration Guide, Version 6.3

496
 CHAPTER 22
Device Management Basics
The following topics describe how to manage devices in the Firepower System:
• The Device Management Page, on page 497
• Remote Management Configuration, on page 498
• Add Devices to the Firepower Management Center, on page 499
• Deleting Devices from the Firepower Management Center, on page 501
• Device Configuration Settings, on page 502
• The Interfaces Table View, on page 513
• Device Group Management, on page 515
• Configuring SNMP for the Firepower 2100 Series, on page 517

The Device Management Page

The Device Management page provides you with a range of information and options that you can use to
manage your registered devices, 7000 and 8000 Series device high availability pairs, and device groups. The
page displays a list of all the devices currently registered on the Firepower Management Center.
This page also displays the number of corrupt devices being managed by the Firepower Management Center.
You can drill down and identify the name / IP address of the corrupt device.
You can use the View by drop-down list to sort and view the device list by any of the following categories:
group, license, model, or access control policy. In a multidomain deployment, you can also sort and view by
domain, which is the default display category in that deployment. Devices must belong to a leaf domain.
You can also view devices by their health monitoring status and their deployment status.
You can expand and collapse the list of devices in any of the device categories. By default, the device list is
expanded.
See the following table for more information about the device list.

Table 47: Device List Fields

Field Description

Name The display name used for the device in Firepower

Management Center. The status icon to the left of the
name indicates its current health status.

Firepower Management Center Configuration Guide, Version 6.3

497
 Appliance Management Basics
Filtering Managed Devices

Field Description

Group The group to which you assigned the managed

devices.

Model The model of the managed devices.

Version The version of the software currently installed on the

managed device.

Licenses The licenses that are enabled on the managed device.

Access Control Policy A link to the currently deployed access control policy.
If the system identifies the access control policy as
out-of-date, it displays a warning icon ( ) next to the
link.

Related Topics
About Firepower Licenses, on page 79
About Health Monitoring, on page 239
Managing Access Control Policies, on page 1354

Filtering Managed Devices

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Leaf only Admin/Network

Admin

When your Firepower Management Center manages a large volume of devices, you can narrow the results
on the Device Management page to make it easier find a particular device.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 In the Search Device field, enter a full or partial device name, host name or IP address to narrow the device
list.
Step 3 To clear the filter, clear the Search Device field.

Remote Management Configuration

Before you can manage a Firepower System device, you must set up a two-way, SSL-encrypted communication
channel between the device and the Firepower Management Center. The appliances use the channel to share
configuration and event information. High availability peers also use the channel, which is by default on port
8305/tcp.

Firepower Management Center Configuration Guide, Version 6.3

498
 Appliance Management Basics
Add Devices to the Firepower Management Center

Note This documentation explains how to configure remote management of a 7000 or 8000 Series device using its
local web interface, before you register the device to the FMC. For information on configuring remote
management for other models, see the appropriate quick start guide.

To enable communications between two appliances, you must provide a way for the appliances to recognize
each other. There are three criteria the Firepower System uses when allowing communications:
• the hostname or IP address of the appliance with which you are trying to establish communication.
In NAT environments, even if the other appliance does not have a routable address, you must provide a
hostname or an IP address either when you are configuring remote management, or when you are adding
the managed appliance.
• a self-generated alphanumeric registration key up to 37 characters in length that identifies the connection.
• an optional unique alphanumeric NAT ID that can help the Firepower System establish communications
in a NAT environment.
The NAT ID must be unique among all NAT IDs used to register managed appliances.

Add Devices to the Firepower Management Center

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Network

Admin

Use this procedure to add a single device to the Firepower Management Center. If you plan to link devices
for redundancy or performance, you must still use this procedure, keeping in mind the following points:
• 8000 Series stacks—Use this procedure to add each device to the Firepower Management Center, then
establish the stack; see Establishing Device Stacks, on page 568.
• 7000 and 8000 Series high availability—Use this procedure to add each device to the Firepower
Management Center, then establish high availability; see Establishing Device High Availability, on page
553. For high availability stacks, first stack the devices, then establish high availability between the stacks.
• 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 717.
• FTD clusters—Make sure cluster units are in a successfully formed cluster on FXOS, then use this
procedure to add one of the cluster units to the Firepower Management Center. the FMC auto-detects all
other cluster members. For more information, see FMC: Add a Cluster, on page 747.

Note If you have established or will establish Firepower Management Center high availability, add devices only to
the active (or intended active) Firepower Management Center. When you establish high availability, devices
registered to the active Firepower Management Center are automatically registered to the standby.

Firepower Management Center Configuration Guide, Version 6.3

499
 Appliance Management Basics
Add Devices to the Firepower Management Center

Before you begin

• Set up the device to be managed by the Firepower Management Center. For 7000 and 8000 Series devices,
see Configuring Remote Management on a Managed Device, on page 524. For information on configuring
remote management for other models, see the appropriate quick start guide.
• If you registered a Firepower Management Center and a device using IPv4 and want to convert them to
IPv6, you must delete and reregister the device.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 From the Add drop-down menu, choose Add 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.
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 Firepower Management Center when you configured the device
to be managed by the Firepower Management Center. For more information, see NAT Environments, on page
475.

Step 4 In the Display Name field, enter a name for the device as you want it to display in the Firepower Management
Center.
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 Firepower Management Center. The registration key is a one-time-use shared secret.
Step 6 In a multidomain deployment, regardless of your current domain, assign the device to a leaf Domain.
If your current domain is a leaf domain, the device is automatically added to the current domain. If your
current domain is not a leaf domain, post-registration, you must switch to the leaf domain to configure the
device.

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.

For Classic devices, note that:
• Control, Malware, and URL Filtering licenses require a Protection license.
• VPN licenses require a 7000 or 8000 Series device.
• Control licenses are supported on NGIPSv andASA FirePOWER devices, but do not allow you to
configure 8000 Series fastpath rules, switching, routing, stacking, or device high availability.

Firepower Management Center Configuration Guide, Version 6.3

500
 Appliance Management Basics
Deleting Devices from the Firepower Management Center

Step 10 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.
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 Firepower Management Center for inspection.
If you disable it, only event information will be sent to the Firepower Management Center but packet data is
not sent.

Step 12 Click Register.

It may take up to two minutes for the Firepower Management Center to verify the device’s heartbeat and
establish communication.

Related Topics
Creating a Basic Access Control Policy, on page 1355

Deleting Devices from the Firepower Management Center

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Network

Admin

If you no longer want to manage a device, you can delete it from the Firepower Management Center. 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 Firepower Management Center via NTP.

To manage the device later, re-add it to the Firepower Management Center.

Note When a device is deleted and then re-added, the Firepower Management Center 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 1 Choose Devices > Device Management.

Step 2 Next to the device you want to delete, click the delete icon ( ).

Firepower Management Center Configuration Guide, Version 6.3

501
 Appliance Management Basics
Device Configuration Settings

Step 3 Confirm that you want to delete the device.

Device Configuration Settings

The Device page of the appliance editor displays detailed device configuration and information. It also allows
you to make changes to some parts of device configuration, such as enabling and disabling licenses, shutting
down and restarting a device, modifying management, and configuring advanced options.

General Device Settings

The General section of the Device tab displays the settings described in the table below.

Table 48: 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
Firepower Threat Defense devices.

Compliance Mode This displays the security certifications compliance

for a device. Valid values are CC, UCAPL and None.

Device License Settings

The License section of the Device tab displays the licenses enabled for the device.
Related Topics
About Firepower Licenses, on page 79

Device System Settings

The System section of the Device tab displays a read-only table of system information, as described in the
following table.

Firepower Management Center Configuration Guide, Version 6.3

502
 Appliance Management Basics
Device Health Settings

Table 49: 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.

Version The version of the software currently installed on the

managed device.

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.

Device Health Settings

The Health section of the Device tab displays the information described in the table below.

Table 50: 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.

Related Topics
Viewing Appliance Health Monitors, on page 258
Editing Health Policies, on page 250
Blacklisting Health Policy Modules, on page 253

Firepower Management Center Configuration Guide, Version 6.3

503
 Appliance Management Basics
Device Management Settings

Device Management Settings

The Management section of the Device tab displays the fields described in the table below.

Table 51: Management Section Table Fields

Field Description

Host The IP address or host name of the device. The host

name is fully qualified domain name or the name that
resolves through the local DNS to a valid IP address
(that is, the host name).

Status An icon indicating the status of the communication

channel between the Firepower Management Center
and the managed device. You can hover over the status
icon to view the last time the Firepower Management
Center contacted the device.

Advanced Device Settings

The Advanced section of the Device tab displays a table of advanced configuration settings, as described
below. You can use the Advanced section to edit any of these settings.

Table 52: Advanced Section Table Fields

Field Description Supported Devices

Application Bypass The state of Automatic Application 7000 & 8000 Series, NGIPSv, ASA
Bypass on the device. FirePOWER , Firepower Threat
Defense

Bypass Threshold The Automatic Application Bypass 7000 & 8000 Series, NGIPSv, ASA
threshold, in milliseconds. FirePOWER , Firepower Threat
Defense

Inspect Local Router Traffic Whether the device inspects traffic 7000 & 8000 Series
received on routed interfaces that
is destined for itself, such as ICMP,
DHCP, and OSPF traffic.

Fast-Path Rules The number of 8000 Series fastpath 8000 Series

rules that have been created on the
device.

Firepower Management Center Configuration Guide, Version 6.3

504
 Appliance Management Basics
Viewing Device Information

Viewing Device Information

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Network

Admin

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 1 Choose Devices > Device Management.

Step 2 Click the edit icon ( ) next to the device you want to view.

In a multidomain deployment, if you are in an ancestor domain, you can click the view icon ( ) to view a
device from a descendant domain in read-only mode.

Step 3 Click the Device tab.

Step 4 You can view the following information:
• General — Displays general settings for the device; see General Device Settings, on page 502.
• License — Displays license information for the device; see Device License Settings, on page 502.
• System — Displays system information about the device; see Device System Settings, on page 502.
• Health — Displays information about the current health status of the device; see Device Health Settings,
on page 503.
• Management — Displays information about the communication channel between the Firepower
Management Center and the device; see Device Management Settings, on page 504.
• Advanced — Displays information about advanced feature configuration; see Advanced Device Settings,
on page 504.

Editing Device Management Settings

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Leaf only Admin/Network

Admin

Note In some cases, if you edit the host name or IP address of a device by another method (using the device’s LCD
panel or CLI, for example), you may need to use the procedure below to manually update the host name or
IP address on the managing Firepower Management Center.

Firepower Management Center Configuration Guide, Version 6.3

505
 Appliance Management Basics
Editing General Device Settings

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to modify management options, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Device tab.

Tip For stacked devices, you modify management options on an individual device on the Device page
of the appliance editor.

Step 4 You can:

• Disable remote management—Click the slider ( ) in the Management section to enable or disable
management of the device. Disabling management blocks the connection between the Firepower
Management Center and the device, but does not delete the device from the Firepower Management
Center. If you no longer want to manage a device, see Deleting Devices from the Firepower Management
Center, on page 501.
• Edit the management host—Click the edit icon ( ) in the Management section, modify the name or IP
address in the Host field, and click Save. You can use this setting to specify the management host name
and regenerate the virtual IP address.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Editing General Device Settings

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Leaf only Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click Device.

Step 4 In the General section, click the edit icon ( ).

Step 5 Enter a Name for the managed device.

Firepower Management Center Configuration Guide, Version 6.3

506
 Appliance Management Basics
Copying Device Configurations

Tip For stacked devices, you edit the assigned device name for the stack on the Stack page of the
appliance editor. You can edit the assigned device name for an individual device on the Devices
page of the appliance editor.

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.
Step 8 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Copying Device Configurations

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.

Smart License Classic License Supported Devices Supported Domains Access

Any Any Firepower Threat Leaf only Admin/Network

Defense Admin

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

Firepower Management Center Configuration Guide, Version 6.3

507
 Appliance Management Basics
Enabling and Disabling Device Licenses

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click Device.

Step 4 In the General section, do one of the following:

• Click the Get Device Configuration icon ( ) 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 the Push Device Configuration icon ( ) 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) Select the Include shared policies configuration checkbox 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 the Tasks tab 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.

Enabling and Disabling Device Licenses

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Leaf only Admin/Network

Admin

You can enable licenses on your device if you have available licenses on your Firepower Management Center.

Procedure

Step 1 Choose Devices > Device Management.

Firepower Management Center Configuration Guide, Version 6.3

508
 Appliance Management Basics
Editing Advanced Device Settings

Step 2 Next to the device where you want to enable or disable licenses, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Device tab.

Tip For stacked devices, you enable or disable the licenses for the stack on the Stack page of the appliance
editor.

Step 4 In the License section, click the edit icon ( ).

Step 5 Check or clear the check box next to the license you want to enable or disable for the managed device.
Step 6 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
About Firepower Licenses, on page 79

Editing Advanced Device Settings

You can configure Application Bypass, Local Router Traffic Inspection, and Fast-Path Rules.

Configuring Automatic Application Bypass

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Leaf only Admin

Network Admin

The Automatic Application Bypass (AAB) feature limits the time allowed to process packets through an
interface and allows packets to bypass detection if the time is exceeded. The feature functions with any
deployment; however, it is most valuable in inline deployments.
You balance packet processing delays with your network’s tolerance for packet latency. When a malfunction
within Snort or a device misconfiguration causes traffic processing time to exceed a specified threshold, AAB
causes Snort to restart within ten minutes of the failure, and generates troubleshoot data that can be analyzed
to investigate the cause of the excessive processing time.
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 troubleshoot
data.
If detection is bypassed, the device generates a health monitoring alert.
By default the AAB is disabled; to enable AAB follow the steps described.

Firepower Management Center Configuration Guide, Version 6.3

509
 Appliance Management Basics
Inspecting Local Router Traffic

Caution AAB activates when an excessive amount of time is spent processing a single packet. 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 312 for more information.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to edit advanced device settings, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Device tab (or the Stack tab for stacked devices), then click the edit icon ( ) in the Advanced
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
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Inspecting Local Router Traffic

Smart License Classic License Supported Devices Supported Domains Access

Any Any 7000 & 8000 Series Leaf only Admin/Network

Admin

If locally-bound traffic matches a Monitor rule in a Layer 3 deployment, that traffic may bypass inspection.
To ensure inspection of the traffic, enable Inspect Local Router Traffic.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to edit advanced device settings, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Device tab (or the Stack tab for stacked devices), then click the edit icon ( ) in the Advanced
section.
Step 4 Check Inspect Local Router Traffic to inspect exception traffic when a 7000 or 8000 Series device is
deployed as a router.

Firepower Management Center Configuration Guide, Version 6.3

510
 Appliance Management Basics
Configuring Fastpath Rules (8000 Series)

Step 5 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring Fastpath Rules (8000 Series)

Smart License Classic License Supported Devices Supported Domains Access

Any Any 8000 Series Leaf only Admin/Network

Admin

As a form of early traffic handling, 8000 Series fastpath rules can send traffic directly through an 8000 Series
device without further inspection or logging. (In a passive deployment, 8000 Series fastpath rules simply stop
analysis.) Each 8000 Series fastpath rule applies to a specific security zone or inline interface set. Because
8000 Series fastpath rules function at the hardware level, you can use only the following simple, outer-header
criteria to fastpath traffic:
• initiator and responder IP address or address block
• protocol, and for TCP and UDP, initiator and responder port
• VLAN ID

By default, 8000 Series fastpath rules affect connections from specified initiators to specified responders. To
fastpath all connections that meets the rule's criteria, regardless of which host is the initiator and which is the
responder, you can make the rule bidirectional.

Note Although they perform a similar function, 8000 Series fastpath rules are not related to the Fastpath tunnel or
prefilter rules that you configure in prefilter policies.

Note When you specify a port other than Any for TCP or UDP traffic, only the first fragment in matching fragmented
traffic is fastpathed. All other fragments are forwarded for further inspection. This is because the 8000 Series
only fastpaths fragmented traffic when the IP header in each fragment contains all the IP header information
needed to match the fastpath rule, and subsequent fragments do not contain the field that identifies the port.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the 8000 Series device where you want to configure the rule, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Firepower Management Center Configuration Guide, Version 6.3

511
 Appliance Management Basics
Managing System Shut Down

Step 3 Click the Device tab (or the Stack tab for stacked devices), then click the edit icon ( ) in the Advanced
section.
Step 4 Click New IPv4 Rule or New IPv6 Rule.
Step 5 From the Domain drop-down list, choose an inline set or passive security zone.
Step 6 Configure the traffic you want to fastpath. Traffic must meet all the conditions to be fastpathed.
• Initiator and Responder (required)—Enter IP addresses or address blocks for initiators and responders.
• Protocol—Choose a protocol, or choose All.
• Initiator Port and Responder Port—For TCP and UDP traffic, enter initiator and responder ports. Leave
the fields blank or enter Any to match all TCP or UDP traffic. You can enter a comma-separated list of
ports, but you cannot enter port ranges.
• VLAN—Enter a VLAN ID. Leave the field blank or enter Any to match all traffic regardless of VLAN
tag.

Step 7 (Optional) Make the rule Bidirectional.

Step 8 Click Save, then Save again.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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 1 Choose Devices > Device Management.

Step 2 Next to the device that you want to restart, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Device tab.

Tip For stacked devices, you shut down or restart an individual device on the Devices page of the
appliance editor.

Firepower Management Center Configuration Guide, Version 6.3

512
 Appliance Management Basics
The Interfaces Table View

Step 4 To shut down the device, click the shut down device icon ( ) in the System section.
Step 5 When prompted, confirm that you want to shut down the device.

Step 6 To restart the device, click the restart device icon ( ).

Step 7 When prompted, confirm that you want to restart the device.

The Interfaces Table View

The interfaces table view is located below the hardware view and 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, as
described in the following tables.

Classic Devices Interfaces

Note that only 8000 Series devices display the MAC Address and IP Address columns. See the table below
for more information.

Firepower Management Center Configuration Guide, Version 6.3

513
 Appliance Management Basics
The Interfaces Table View

Table 53: Classic Devices Interfaces Table View Fields

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 the interface type, speed, and duplex mode
(if applicable) in a tooltip. The interface icons are
described in Interface Icons, on page 526.
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 ( )

Logical interfaces have the same link state as their

parent physical interface. 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 hybrid and
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.
Physical interfaces display the name of the physical
interface. Logical interfaces display the name of the
physical interface and the assigned VLAN tag.
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 the edit icon ( ).

Used by The inline set, virtual switch, or virtual router where

the interface is assigned. ASA FirePOWER modules
do not display the Used by column.

Firepower Management Center Configuration Guide, Version 6.3

514
Appliance Management Basics
Device Group Management

Field Description

MAC Address The MAC address displayed for the interface when it
is enabled for switched and routed features.
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. ASA FirePOWER modules do not
display MAC addresses.

IP Addresses IP addresses assigned to the interface. Hover your

pointer over an IP address to view whether it is active
or inactive. Inactive IP addresses are grayed out. ASA
FirePOWER modules do not display IP addresses.

FTD Interfaces

Table 54: FTD Interfaces Table View Fields

Field Description

Interface The interface IDs. For the failover link or cluster

control link interface, the interface settings are
view-only.
Logical Name The configured name of the interface.

Type The type of interface: Physical, SubInterface,

EtherChannel, Redundant, or BridgeGroup
(transparent firewall mode only).
Interface Object The security zone or interface group where the
interface is assigned.

MAC Address (Active/Standby) The interface MAC address(es). For High Availability,
this column shows both the active MAC address and
the standby MAC address.

IP Address The IP addresses assigned to the interface. The type

of address assignment shows in parentheses: Static,
DHCP, or PPPoE.

Device Group Management

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. The list appears
collapsed by default.
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.

Firepower Management Center Configuration Guide, Version 6.3

515
 Appliance Management Basics
Adding Device Groups

Adding Device Groups

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Leaf only Admin/Network

Admin

Device groups enable you to easily assign policies and install updates on multiple devices.
If you add the primary device in a stack or a high-availability pair to a group, both devices are added to the
group. If you unstack the devices or break the high-availability pair, both devices remain in that group.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 From the Add drop-down menu, choose Add Group.
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 Click OK to add the device group.

Editing Device Groups

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Leaf only Admin/Network

Admin

You can change the set of devices that reside in any device group. You must remove an appliance from its
current group before you can add it to a new group.
Moving an appliance to a new group does not change its policy to the policy previously assigned to the group.
You must assign the group's policy to the new device.
If you add the primary device in a stack or a device high-availability pair to a group, both devices are added
to the group. If you unstack the devices or break the high-availability pair, both devices remain in that group.
In a multidomain deployment, you can only edit device groups in the domain where they were created.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device group you want to edit, click the edit icon ( ).
Step 3 Optionally, in the Name field, enter a new name for the group.

Firepower Management Center Configuration Guide, Version 6.3

516
 Appliance Management Basics
Configuring SNMP for the Firepower 2100 Series

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 the delete icon ( ) next to the device you want
to remove.
Step 7 Click OK to save the changes to the device group.

Configuring SNMP for the Firepower 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 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 2100 chassis supports SNMPv1, SNMPv2c and SNMPv3. Both SNMPv1 and SNMPv2c use
a community-based form of security.

Enabling SNMP and Configuring SNMP Properties for Firepower 2100

Note This procedure only applies to Firepower 2100 series devices.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Click the SNMP tab.
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.

Firepower Management Center Configuration Guide, Version 6.3

517
 Appliance Management Basics
Creating an SNMP Trap for Firepower 2100

Name Description
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.

Creating an SNMP Trap for Firepower 2100

Note This procedure only applies to Firepower 2100 series devices.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Click the SNMP tab.
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.

Firepower Management Center Configuration Guide, Version 6.3

518
 Appliance Management Basics
Creating an SNMP User for Firepower 2100

Name Description
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.

Step 6 Click Save.

Creating an SNMP User for Firepower 2100

Note This procedure only applies to Firepower 2100 series devices.

Firepower Management Center Configuration Guide, Version 6.3

519
 Appliance Management Basics
Creating an SNMP User for Firepower 2100

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Click the SNMP tab.
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.

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.

Firepower Management Center Configuration Guide, Version 6.3

520
PA R T VI
Classic Device Configuration Basics
• Classic Device Management Basics, on page 523
• IPS Device Deployments and Configuration, on page 535
 CHAPTER 23
Classic Device Management Basics
The following topics describe how to manage Classic devices (7000 and 8000 Series devices, ASA with
FirePOWER Services, and NGIPSv) in the Firepower System:
• Remote Management Configuration, on page 523
• Interface Configuration Settings, on page 526

Remote Management Configuration

Before you can manage a Firepower System device, you must set up a two-way, SSL-encrypted communication
channel between the device and the Firepower Management Center. The appliances use the channel to share
configuration and event information. High availability peers also use the channel, which is by default on port
8305/tcp.

Note This documentation explains how to configure remote management of a 7000 or 8000 Series device using its
local web interface, before you register the device to the FMC. For information on configuring remote
management for other models, see the appropriate quick start guide.

To enable communications between two appliances, you must provide a way for the appliances to recognize
each other. There are three criteria the Firepower System uses when allowing communications:
• the hostname or IP address of the appliance with which you are trying to establish communication.
In NAT environments, even if the other appliance does not have a routable address, you must provide a
hostname or an IP address either when you are configuring remote management, or when you are adding
the managed appliance.
• a self-generated alphanumeric registration key up to 37 characters in length that identifies the connection.
• an optional unique alphanumeric NAT ID that can help the Firepower System establish communications
in a NAT environment.
The NAT ID must be unique among all NAT IDs used to register managed appliances.

Firepower Management Center Configuration Guide, Version 6.3

523
 Classic Device Configuration Basics
Configuring Remote Management on a Managed Device

Configuring Remote Management on a Managed Device

Smart License Classic License Supported Devices Supported Domains Access

Any Any 7000 & 8000 Series N/A Admin/Network

Admin

Procedure

Step 1 On the web interface for the device you want to manage, choose System > Integration > Remote Management.
Step 2 Click the Remote Management tab, if it is not already displaying.
Step 3 Click Add Manager.
Step 4 In the Management Host field, enter one of the following for the Firepower Management Center that you
want to use to manage this appliance:
• The IP address
• The fully qualified domain name or the name that resolves through the local DNS to a valid IP address
(that is, the host name)
Caution Use a host name rather than an IP address if your network uses DHCP to assign IP addresses.

In a NAT environment, you do not need to specify an IP address or host name here if you plan to specify it
when you add the managed appliance. In this case, the Firepower System uses the NAT ID you will provide
later to identify the remote manager on the managed appliance’s web interface.

Step 5 In the Registration Key field, enter the registration key that you want to use to set up communications between
appliances.
Step 6 For NAT environments, in the Unique NAT ID field, enter a unique alphanumeric NAT ID that you want
to use to set up communications between appliances.
Step 7 Click Save.

What to do next
• Wait until the appliances confirm that they can communicate with each other and the Pending Registration
status appears.
• Add this device to the Firepower Management Center; see Add Devices to the Firepower Management
Center, on page 499.

Editing Remote Management on a Managed Device

Smart License Classic License Supported Devices Supported Domains Access

Any Any 7000 & 8000 Series N/A Admin/Network

Admin

When editing a remote manager, note that:

Firepower Management Center Configuration Guide, Version 6.3

524
 Classic Device Configuration Basics
Changing the Management Port

• The Host field specifies the fully qualified domain name or the name that resolves through the local DNS
to a valid IP address (that is, the host name).
• The Name field specifies the display name of the managing 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 managing device.

Procedure

Step 1 On the web interface for the device, choose System > Integration.
Step 2 Click the Remote Management tab, if it is not already displaying.
Step 3 You can:
• Disable remote management — Click the slider next to the manager to enable or disable it. Disabling
management blocks the connection between the Firepower Management Center and the device, but does
not delete the device from the Firepower Management Center. If you no longer want to manage a device,
see Deleting Devices from the Firepower Management Center, on page 501.
• Edit manager information — Click the edit icon ( ) next to the manager you want to modify, modify
the Name and Host fields, and click Save.

Changing the Management Port

Smart License Classic License Supported Devices Supported Domains Access

Any Any 7000 & 8000 Series Global only Admin/Network

Admin
FMC

Appliances communicate using a two-way, SSL-encrypted communication channel, which by default is on

port 8305.
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 of the Firepower System.

Caution If you change the management port, you must change it for all appliances in your deployment that need to
communicate with each other.

Procedure

Step 1 Choose System > Configuration.

Step 2 Click Management Interfaces.

Firepower Management Center Configuration Guide, Version 6.3

525
 Classic Device Configuration Basics
Interface Configuration Settings

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 Physical Hardware View

The top of the Interfaces page provides a graphical representation of the physical hardware view of a 7000 or
8000 Series device.
Use the physical hardware view to:
• view a network module’s type, part number, and serial number
• select an interface in the interfaces table view
• open an interface editor
• view the name of the interface, the type of interface, whether the interface has link, the interface’s speed
setting, and whether the interface is currently in bypass mode
• view the details about an error or warning

Interface Icons
Table 55: Interface Icon Types and Descriptions

Icon Interface Type For more information, see...

Physical — an unconfigured Configuring Physical Switched

physical interface. Interfaces, on page 1271 or
Configuring Physical Routed
Interfaces, on page 1281

Passive — a sensing interface Configuring Passive Interfaces, on

configured to analyze traffic in a page 536
passive deployment.

Firepower Management Center Configuration Guide, Version 6.3

526
 Classic Device Configuration Basics
Using the Physical Hardware View

Icon Interface Type For more information, see...

Inline — a sensing interface Configuring Inline Interfaces, on

configured to handle traffic in an page 539
inline deployment.

Switched — an interface Switched Interface Configuration,

configured to switch traffic in a on page 1269
Layer 2 deployment.

Routed — an interface configured Routed Interfaces, on page 1280

to route traffic in a Layer 3
deployment.

Aggregate — multiple physical About Aggregate Interfaces, on

interfaces configured as a single page 1311
logical link.

Aggregate Switched — multiple Adding Aggregate Switched

physical interfaces configured as a Interfaces, on page 1317
single logical link in a Layer 2
deployment.

Aggregate Routed — multiple Adding Aggregate Routed

physical interfaces configured as a Interfaces, on page 1319
single logical link in a Layer 3
deployment.

Hybrid — a logical interface Logical Hybrid Interfaces, on page

configured to bridge traffic between 1325
a virtual router and a virtual switch.

ASA FirePOWER — an interface Managing Cisco ASA FirePOWER

configured on an ASA device with Interfaces, on page 531
the ASA FirePOWER module
installed.

Using the Physical Hardware View

Smart License Classic License Supported Devices Supported Domains Access

Any Any 7000 & 8000 Series Any Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Click the edit icon ( ) next to the device you want to manage.
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Firepower Management Center Configuration Guide, Version 6.3

527
 Classic Device Configuration Basics
Configuring Sensing Interfaces

Step 3 Use the graphical interface to:

• Choose — If you want to choose an interface, click the interface icon. The system highlights the related
entry in the interface table.
• Edit — If you want to open an interface editor, double-click the interface icon.
• View error or warning information — If you want to view the details about an error or warning, hover
your cursor over the affected port on the network module.
• View interface information — If you want to view the name of the interface, the type of interface, whether
the interface has link, the interface’s speed setting, and whether the interface is currently in bypass mode,
hover your cursor over the interface.
• View network module information — If you want to view a network module’s type, part number, and
serial number, hover your cursor over the dark circle in the lower left corner of the network module.

Configuring Sensing Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Any Classic Leaf only Admin/Network

Admin

You can configure the sensing interfaces of a managed device, according to your Firepower System 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 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to configure an interface, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the edit icon ( ) next to the interface you want to configure.
Step 4 Use the interface editor to configure the sensing interface:
• HA Link — If you want an interface configured on each member of a high-availability pair of devices
to act as a redundant communications channel between the devices; also called a high availability link
interface, click HA Link and proceed as described in Configuring HA Link Interfaces, on page 529.
• 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 539.
• 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 536.

Firepower Management Center Configuration Guide, Version 6.3

528
 Classic Device Configuration Basics
Configuring HA Link Interfaces

• Routed — If you want an interface configured to route traffic in a Layer 3 deployment, click Routed
and proceed as described in Routed Interfaces, on page 1280.
• Switched — If you want an interface configured to switch traffic in a Layer 2 deployment, click Switched
and proceed as described in Switched Interface Configuration, on page 1269.

Step 5 Click Save to complete your configuration.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring HA Link Interfaces

Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 & 8000 Series Leaf only Admin/Network

Admin

After you establish a 7000 or 8000 Series device high-availability pair, you should configure a physical
interface as a high availability (HA) link interface. This link acts as a redundant communications channel for
sharing health information between the paired devices. When you configure an HA link interface on one
device, you automatically configure an interface on the second device. You must configure both HA links on
the same broadcast domain.
Dynamic NAT relies on dynamically allocating IP addresses and ports to map to other IP addresses and ports.
Without an HA link, these mappings are lost in a failover, causing all translated connections to fail as they
are routed through the now-active device in the high-availability pair.
Similarly, 7000 or 8000 Series devices with high-availability state sharing, dynamic NAT, or VPN require
an HA link interface.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the peer where you want to configure the HA link interface, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Next to the interface you want to configure as a HA link interface, click the edit icon ( ).
Step 4 Click HA Link.
Step 5 Check the Enabled check box.
Note If you clear the check box, the system administratively takes down the interface, disabling it.

Step 6 From the Mode drop-down list, choose an option to designate the link mode, or choose Autonegotiation to
specify that the interface is configured to autonegotiate speed and duplex settings.

Firepower Management Center Configuration Guide, Version 6.3

529
 Classic Device Configuration Basics
Disabling Interfaces

Step 7 From the MDI/MDIX drop-down list, choose an option to designate whether the interface is configured for
MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
Note Normally, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI
and MDIX to attain link.

Step 8 Enter a maximum transmission unit (MTU) in the MTU field.

The range of MTU values can vary depending on the model of the managed device and the interface type.
See MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532 for more information.
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 312 for
more information.

Step 9 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Snort® Restart Scenarios, on page 311
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532

Disabling Interfaces
Smart License Classic License Supported Devices Supported Domains Access

Any Any 7000 & 8000 Series Leaf only Admin/Network

Admin
NGIPSv

You can disable an interface by setting the interface type to None. Disabled interfaces appear grayed out in
the interface list.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to disable the interface, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Next to the interface you want to disable, click the edit icon ( ).
Step 4 Click None.

Firepower Management Center Configuration Guide, Version 6.3

530
 Classic Device Configuration Basics
Managing Cisco ASA FirePOWER Interfaces

Step 5 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Managing Cisco ASA FirePOWER Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection ASA FirePOWER Leaf only Admin/Network

Admin

When editing an ASA FirePOWER interface, you can configure only the interface’s security zone from the
Firepower Management Center.
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 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to edit the interface, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Interfaces tab if it is not already displaying.

Step 4 Next to the interface you want to edit, click the edit icon ( ).
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
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

531
 Classic Device Configuration Basics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv

MTU Ranges for 7000 and 8000 Series Devices and 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 312 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.

Classic Device Model MTU Range

7000 & 8000 Series 576-9234 (management interface)

576-10172 (inline sets, passive interface)
576-9922 (all others)

NGIPSv 576-9018 (all interfaces, inline sets)

Related Topics
About the MTU, on page 664

Synchronizing Security Zone Object Revisions

Smart License Classic License Supported Devices Supported Domains Access

Any Any 7000 & 8000 Series Leaf only Admin/Network

Admin
NGIPSv

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.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to update the security zone selection, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

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.

Firepower Management Center Configuration Guide, Version 6.3

532
Classic Device Configuration Basics
Synchronizing Security Zone Object Revisions

Step 4 Repeat steps 2 through 3 for each device logging duplicate events. You must edit all devices before you
continue.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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.

Firepower Management Center Configuration Guide, Version 6.3

533
 Classic Device Configuration Basics
Synchronizing Security Zone Object Revisions

Firepower Management Center Configuration Guide, Version 6.3

534
 CHAPTER 24
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 535
• Passive IPS Deployments, on page 535
• Inline IPS Deployments, on page 537

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.

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 or mirror 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.

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. Interfaces on 8000 Series appliances do not support half-duplex
options.
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.

Firepower Management Center Configuration Guide, Version 6.3

535
 Classic Device Configuration Basics
Configuring Passive Interfaces

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 312 for more information.

Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Configuring Passive Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection feature dependent Leaf only Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Click the edit icon ( ) next to the device where you want to configure the passive interface.
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the edit icon ( ) 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 380.

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 7000 & 8000 Series only: From the Mode drop-down list, designate the link mode, or choose Autonegotiation
to specify that the interface is configured to automatically negotiate speed and duplex settings.
Mode settings are available only for copper interfaces.
Interfaces on 8000 Series appliances do not support half-duplex options.

Step 8 7000 & 8000 Series only: From the MDI/MDIX drop-down list, designate whether the interface is configured
for MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
MDI/MDIX settings are available only for copper interfaces.

Firepower Management Center Configuration Guide, Version 6.3

536
 Classic Device Configuration Basics
Inline IPS Deployments

By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and
MDIX to attain link.

Step 9 Enter a maximum transmission unit (MTU) in the MTU field.

The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 312 for
more information.

Step 10 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Inline IPS Deployments

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.
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.

Firepower Management Center Configuration Guide, Version 6.3

537
 Classic Device Configuration Basics
Inline Interfaces on the Firepower System

Note If you assign multiple interface pairs to a single inline interface set but you experience issues with duplicate
traffic, reconfigure to help the system uniquely identify packets. For example, you could reassign your interface
pairs to separate inline sets or modify your security zones.

For devices with inline sets, a software bridge is automatically set up to transport packets after the device
restarts. If the device is restarting, there is no software bridge running anywhere. If you enable bypass mode
on the inline set, it goes into hardware bypass while the device is restarting. In that case, you may lose a few
seconds of packets as the system goes down and comes back up, due to renegotiation of link with the device.
However, the system will pass traffic while Snort is restarting.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

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:

Firepower Management Center Configuration Guide, Version 6.3

538
 Classic Device Configuration Basics
Configuring Inline Interfaces

• 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

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection feature dependent Leaf only Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Click the edit icon ( ) next to the device where you want to configure the interface.
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the edit icon ( ) 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 380.

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 542.

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 7000 & 8000 Series only: From the Mode drop-down list, designate the link mode, or choose Autonegotiation
to specify that the interface is configured to automatically negotiate speed and duplex settings.
Mode settings are available only for copper interfaces.
Interfaces on 8000 Series appliances do not support half-duplex options.

Step 9 7000 & 8000 Series only: From the MDI/MDIX drop-down list, designate whether the interface is configured
for MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
MDI/MDIX settings are available only for copper interfaces.

Firepower Management Center Configuration Guide, Version 6.3

539
 Classic Device Configuration Basics
Inline Sets on the Firepower System

By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and
MDIX to attain link.

Step 10 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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
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 312 for more information.

Firepower Management Center Configuration Guide, Version 6.3

540
 Classic Device Configuration Basics
Viewing Inline Sets

Failsafe
Behavior of the interface on a 7000 or 8000 Series or NGIPSv device when the Snort process is busy or down.
• Enabled—New and existing flows pass without inspection when the Snort process is busy or down.
• Disabled—New and existing flows drop when the Snort process is busy and pass without inspection
when the Snort process is down.

The Snort process can be busy when traffic buffers are full, indicating that there is more traffic than the
managed device can handle, or because of other software issues.
The Snort process goes down when you deploy a configuration that requires it to restart. See Configurations
that Restart the Snort Process When Deployed or Activated, on page 313 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.

Bypass Mode
Firepower 7000 or 8000 Series only: The configured bypass mode of the inline set. This setting determines
how the relays in the inline interfaces respond when an interface fails. The bypass mode allows traffic to
continue to pass through the interfaces. The non-bypass mode blocks traffic.

Caution In bypass mode, you may lose a few packets when you reboot the appliance. You cannot configure bypass
mode for inline sets on 7000 or 8000 Series devices in a high-availability pair, inline sets on an NGIPSv
device, for non-bypass NetMods on 8000 Series devices, or for SFP modules on Firepower 7115 or 7125
devices.

Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Viewing Inline Sets

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Click the edit icon ( ) next to the device where you want to view the inline sets.
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Firepower Management Center Configuration Guide, Version 6.3

541
 Classic Device Configuration Basics
Adding Inline Sets

Step 3 Click the Inline Sets tab.

Adding Inline Sets

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection feature dependent Leaf only Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Click the edit icon ( ) next to the device where you want to add the inline set.
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Inline Sets tab.

Step 4 Click Add Inline Set.
Step 5 Enter a Name.

Step 6 Next to Interfaces, choose one or more inline interface pairs, then click the add selected icon ( ). To add
all interface pairs to the inline set, click the add all icon ( ).
Tip To remove inline interfaces from the inline set, choose one or more inline interface pairs and click
the remove selected icon ( ). To remove all interface pairs from the inline set, click the remove
all icon ( ). Disabling either interface in a pair from the Interfaces tab also removes the pair.

Step 7 Enter a maximum transmission unit (MTU) in the MTU field.

The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 312 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 540 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 7000 and 8000 Series only: Specify the bypass mode:

Firepower Management Center Configuration Guide, Version 6.3

542
 Classic Device Configuration Basics
Advanced Inline Set Options

• Click Bypass to allow traffic to continue to pass through the interfaces.

• Click Non-Bypass to block traffic.
Note You cannot configure bypass mode for inline sets on 7000 or 8000 Series devices in high-availability
pairs, inline sets on an NGIPSv device, for non-bypass NetMods on 8000 Series devices, or for SFP
modules on Firepower 7115 or 7125 devices.

Step 10 Optionally, configure advanced settings; see Advanced Inline Set Options, on page 543.
Step 11 Click OK.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Advanced Inline Set Options

There are a number of advanced options you may consider as you configure inline sets.

Tap Mode
Tap mode is available on 7000 and 8000 Series devices when you create an inline or inline with fail-open
interface set.
With tap mode, the device is deployed inline, but instead of the packet flow passing through the device, a
copy of each packet is sent to the device and the network traffic flow is undisturbed. Because you are working
with copies of packets rather than the packets themselves, rules that you set to drop and rules that use the
replace keyword do not affect the packet stream. However, 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 devices that are deployed inline. For example, you can set up the
cabling between the device and the network as if the device were inline and analyze the kinds of intrusion
events the device 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 device
inline, you can disable tap mode and begin dropping suspicious traffic without having to reconfigure the
cabling between the device and the network.
Note that you cannot enable this option and strict TCP enforcement on the same inline set.

Propagate Link State

Note Link state propagation is not supported on virtual devices.

Firepower Management Center Configuration Guide, Version 6.3

543
 Classic Device Configuration Basics
Configuring Advanced Inline Set Options

Link state propagation is a feature for inline sets configured in bypass mode and non-bypass mode so both
pairs of an inline set track state. Link state propagation is available for both copper and fiber configurable
bypass interfaces.
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 appliance
senses the change and updates the link state of the other interface to match it. Note that appliances 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.
Note that only 7000 and 8000 Series devices support link state propagation.
You cannot disable link state propagation for inline sets configured on 7000 and 8000 Series devices in
high-availability pairs.

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. Note that you cannot disable
this option on 7000 and 8000 Series devices.

Strict TCP Enforcement

Note Strict TCP enforcement is not supported on virtual devices.

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

Note that only 7000 and 8000 Series devices support this option. In addition, you cannot enable this option
and tap mode on the same inline set.

Configuring Advanced Inline Set Options

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection feature dependent Leaf only Admin/Network

Admin

Firepower Management Center Configuration Guide, Version 6.3

544
 Classic Device Configuration Basics
Deleting Inline Sets

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Click the edit icon ( ) next to the device where you want to edit the inline set.
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Inline Sets tab.

Step 4 Click the edit icon ( ) next to the inline set you want to edit.
Step 5 Click the Advanced tab.
Step 6 Configure options as described in Advanced Inline Set Options, on page 543.
Note Link state propagation and strict TCP enforcement are not supported on virtual devices.

Step 7 Click OK.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Deleting Inline Sets

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Leaf only Admin/Network

Admin

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 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to delete the inline set, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Inline Sets tab.

Step 4 Next to the inline set you want to delete, click the delete icon ( ).
Step 5 When prompted, confirm that you want to delete the inline set.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

545
 Classic Device Configuration Basics
Deleting Inline Sets

Firepower Management Center Configuration Guide, Version 6.3

546
PA R T VII
Classic Device High Availability and Scalability
• 7000 and 8000 Series Device High Availability, on page 549
• 8000 Series Device Stacking, on page 565
 CHAPTER 25
7000 and 8000 Series Device High Availability
The following topics describe how to configure high availability for Firepower 7000 Series and 8000 Series
devices in the Firepower System:
• About 7000 and 8000 Series Device High Availability, on page 549
• Establishing Device High Availability, on page 553
• Editing Device High Availability, on page 554
• Configuring Individual Devices in a High-Availability Pair, on page 555
• Configuring Individual Device Stacks in a High-Availability Pair, on page 555
• Configuring Interfaces on a Device in a High-Availability Pair, on page 556
• Switching the Active Peer in a Device High-Availability Pair, on page 557
• Placing a High-Availability Peer into Maintenance Mode, on page 557
• Replacing a Device in a Stack in a High-Availability Pair, on page 558
• Device High Availability State Sharing, on page 558
• Device High Availability State Sharing Statistics for Troubleshooting, on page 561
• Separating Device High-Availability Pairs, on page 564

About 7000 and 8000 Series Device High Availability

With 7000 and 8000 Series device high availability, you can establish redundancy of networking functionality
and configuration data between two peer devices or two peer device stacks.
You achieve configuration redundancy by configuring two peer devices or two peer device stacks into a
high-availability pair to act as a single logical system for policy deploys, system updates, and registration.
The system automatically synchronizes other configuration data.

Note Static routes, non-SFRP IP addresses, and routing priorities are not synchronized between the peer devices
or peer device stacks. Each peer device or peer device stack maintains its own routing intelligence.

Related Topics
SFRP
Advanced Virtual Switch Settings, on page 1275

Firepower Management Center Configuration Guide, Version 6.3

549
 Classic Device High Availability and Scalability
Device High Availability Requirements

Device High Availability Requirements

Before you can configure a 7000 and 8000 Series device high-availability pair, the following must be true:
• You can only pair single devices with single devices or device stacks with device stacks.
• Both devices or device stacks must have normal health status, be running the same software, and have
the same licenses. See Using the Health Monitor, on page 256 for more information. In particular, the
devices cannot have hardware failures that would cause them to enter maintenance mode and trigger a
failover.

Note After you pair the devices, you cannot change the license options for individual
paired devices, but you can change the license for the entire high-availability
pair.

• Interfaces must be configured on each device or each primary device in a stack.

• Both devices or the primary members of the device stacks must be the same model and have identical
copper or fiber interfaces.
• Device stacks must have identical hardware configurations, except for an installed malware storage pack.
For example, you can pair a Firepower 8290 with another 8290. None, one, or all devices in either stack
might have a malware storage pack.

Caution Do not attempt to install a hard drive that was not supplied by Cisco in your
device. Installing an unsupported hard drive may damage the device. Malware
storage pack kits are available for purchase only from Cisco, and are for use only
with 8000 Series devices. Contact Support if you require assistance with the
malware storage pack. See the Firepower System Malware Storage Pack Guide
for more information.

• If the devices are targeted by NAT policies, both peers must have the same NAT policy.
• In a multidomain deployment, you can only establish 7000 or 8000 Series device high-availability or
device stacks within a leaf domain.

Note After failover and recovery, SFRP preempts to the master node.

Device High Availability Failover and Maintenance Mode

With a 7000 and 8000 Series device high availability, the system fails over either manually or automatically.
You manually trigger failover by placing one of the paired devices or stacks in maintenance mode.
Automatic failover occurs after the health of the active device or stack becomes compromised, during a system
update, or after a user with Administrator privileges shuts down the device. Automatic failover also occurs
after an active device or device stack experiences NMSB failure, NFE failure, hardware failure, firmware

Firepower Management Center Configuration Guide, Version 6.3

550
 Classic Device High Availability and Scalability
Configuration Deployment and Upgrade Behavior for High-Availability Pairs

failure, critical process failure, a disk full condition, or link failure between two stacked devices. If the health
of the standby device or stack becomes similarly compromised, the system does not fail over and enters a
degraded state. The system also does not fail over when one of the devices or device stacks is in maintenance
mode. Note that disconnecting the stacking cable from an active stack sends that stack into maintenance mode.
Shutting down the secondary device in an active stack also sends that stack into maintenance mode.

Note If the active member of the high-availability pair goes into maintenance mode and the active role fails over
to the other pair member, when the original active pair member is restored to normal operation it does not
automatically reclaim the active role.

Configuration Deployment and Upgrade Behavior for High-Availability Pairs

This topic describes upgrade and deployment behavior for 7000 and 8000 Series devices (and stacks) in high
availability pairs.

Behavior During Deploy

You deploy configuration changes to the members of a high availability pair at the same time. Deploy either
succeeds or fails for both peers. The Firepower Management Center deploys to the active device; if that
succeeds then changes are deployed to the standby.

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 312 and Configurations that Restart the
Snort Process When Deployed or Activated, on page 313.

Behavior During Upgrade

You should not experience interruptions in traffic flow or inspection while upgrading devices (or device
stacks) in high availability pairs. To ensure continuity of operations, they upgrade one at a time. Devices
operate in maintenance mode while they upgrade.
Which peer upgrades first depends on your deployment:
• Routed or switched—Standby 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.
• Access control only— Active upgrades first. When the upgrade completes, the active and standby maintain
their old roles.

Deployment Types and Device High Availability

You determine how to configure 7000 or 8000 Series device high availability depending on your Firepower
System deployment: passive, inline, routed, or switched. You can also deploy your system in multiple roles
at once. Of the four deployment types, only passive deployments require that you configure devices or stacks

Firepower Management Center Configuration Guide, Version 6.3

551
 Classic Device High Availability and Scalability
Deployment Types and Device High Availability

using high availability to provide redundancy. You can establish network redundancy for the other deployment
types with or without device high availability. For a brief overview on high availability in each deployment
type, see the sections below.

Note You can achieve Layer 3 redundancy without using device high availability by using the Cisco Redundancy
Protocol (SFRP). SFRP allows devices to act as redundant gateways for specified IP addresses. With network
redundancy, you configure two devices or stacks to provide identical network connections, ensuring connectivity
for other hosts on the network.

Passive Deployment Redundancy

Passive interfaces are generally connected to tap ports on central switches, which allows them to analyze all
of the traffic flowing across the switch. If multiple devices are connected to the same tap feed, the system
generates events from each of the devices. When configured in a high-availability pair, devices act as either
active or standby, which allows the system to analyze traffic even in the event of a system failure while also
preventing duplicate events.

Inline Deployment Redundancy

Because an inline set has no control over the routing of the packets being passed through it, it must always
be active in a deployment. Therefore, redundancy relies on external systems to route traffic correctly. You
can configure redundant inline sets with or without 7000 or 8000 Series device high availability.
To deploy redundant inline sets, you configure the network topology so that it allows traffic to pass through
only one of the inline sets while preventing circular routing. If one of the inline sets fails, the surrounding
network infrastructure detects the loss of connectivity to the gateway address and adjusts the routes to send
traffic through the redundant set.

Routed Deployment Redundancy

Hosts in an IP network must use a well-known gateway address to send traffic to different networks. Establishing
redundancy in a routed deployment requires that routed interfaces share the gateway addresses so that only
one interface handles traffic for that address at any given time. To accomplish this, you must maintain an
equal number of IP addresses on a virtual router. One interface advertises the address. If that interface goes
down, the standby interface begins advertising the address.
In devices that are not members of a high-availability pair, you use SFRP to establish redundancy by configuring
gateway IP addresses shared between multiple routed interfaces. You can configure SFRP with or without
7000 or 8000 Series device high availability. You can also establish redundancy using dynamic routing such
as OSPF or RIP.

Switched Deployment Redundancy

You establish redundancy in a switched deployment using the Spanning Tree Protocol (STP), one of the
advanced virtual switch settings. STP is a protocol that manages the topology of bridged networks. It is
specifically designed to allow redundant links to provide automatic standby for switched interfaces without
configuring standby links. Devices in a switched deployment rely on STP to manage traffic between redundant
interfaces. Two devices connected to the same broadcast network receive traffic based on the topology
calculated by STP.

Firepower Management Center Configuration Guide, Version 6.3

552
 Classic Device High Availability and Scalability
Device High Availability Configuration

Note Cisco strongly recommends that you enable STP when configuring a virtual switch that you plan to deploy
in a 7000 or 8000 Series device high-availability pair.

Device High Availability Configuration

When establishing 7000 or 8000 Series device high availability, you designate one of the devices or stacks
as active and the other as standby. The system applies a merged configuration to the paired devices. If there
is a conflict, the system applies the configuration from the device or stack you designated as active.
After you pair the devices, you cannot change the license options for individual paired devices, but you can
change the license for the entire high-availability pair. If there are interface attributes that need to be set on
switched interfaces or routed interfaces, the system establishes the high-availability pair, but sets it to a pending
status. After you configure the necessary attributes, the system completes the high-availability pair and sets
it to a normal status.
After you establish a high-availability pair, the system treats the peer devices or stacks as a single device on

the Device Management page. Device high-availability pairs display the High Availability icon ( ) in the
appliance list. Any configuration changes you make are synchronized between the paired devices. The Device
Management page displays which device or stack in the high-availability pair is active, which changes after
manual or automatic failover.
Removing registration of a device high-availability pair from a Firepower Management Center removes
registration from both devices or stacks. You remove a device high-availability pair from the Firepower
Management Center as you would an individual managed device.
You can then register the high-availability pair on another Firepower Management Center. To register single
devices from a high-availability pair, you add remote management to the active device in the pair and then
add that device to the Firepower Management Center, which adds the whole pair. To register stacked devices
in a high-availability pair, you add remote management to the primary device of the either stack and then add
that device to the Firepower Management Center, which adds the whole pair.
After you establish a device high-availability pair, you should configure a high-availability link interface.

Note If you plan to set up dynamic NAT, HA state sharing, or VPN using the devices in the high-availability pair,
you must configure a high-availability link interface. For more information, see Configuring HA Link Interfaces,
on page 529.

Establishing Device High Availability

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Any Admin/Network

Admin

Firepower Management Center Configuration Guide, Version 6.3

553
 Classic Device High Availability and Scalability
Editing Device High Availability

Note This procedure describes establishing a 7000 & 8000 Series device high-availability pair. For information on
establishing Firepower Threat Defense high availability, see Add a Firepower Threat Defense High Availability
Pair, on page 717.

When establishing a 7000 & 8000 Series device high-availability pair, you designate one of the devices or
stacks as active and the other as standby. The system applies a merged configuration to the paired devices. If
there is a conflict, the system applies the configuration from the device or stack you designated as active.
In a multidomain deployment, devices in a high-availability pair must belong to the same domain.

Before you begin

• Confirm that all requirements are met; see Device High Availability Requirements, on page 550.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 From the Add drop-down menu, choose Add High Availability.
Step 3 Enter a Name.
Step 4 Under Device Type, choose Firepower.
Step 5 Assign roles for the devices or stacks:
a) Choose the Active Peer device or stack for the high-availability pair.
b) Choose the Standby Peer device or stack for the high-availability pair.
Step 6 Click Add. The process takes a few minutes as the system synchronizes data.

What to do next
Create an HA Link interface on each of the devices in the high-availability pair if you plan to set up HA state
sharing, dynamic NAT, or VPN with the devices. For more information on HA link interfaces, see Configuring
HA Link Interfaces, on page 529.

Editing Device High Availability

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Leaf only Admin/Network

Admin

After you establish a 7000 or 8000 Series device high-availability pair, most changes you make to the device
configuration also change the configuration of the whole high-availability pair.
You can view the status of the high-availability pair by hovering your pointer over the status icon in the
General section. You can also view which device or stack is the active peer and standby peer in the pair.

Firepower Management Center Configuration Guide, Version 6.3

554
 Classic Device High Availability and Scalability
Configuring Individual Devices in a High-Availability Pair

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device high availability pair where you want to edit the configuration, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Use the sections on the High Availability page to make changes to the high-availability pair configuration as
you would a single device configuration.

Configuring Individual Devices in a High-Availability Pair

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Leaf only Admin/Network

Admin

After you establish a 7000 or 8000 Series device high-availability pair, you can still configure some attributes
for each device within the pair. You can make changes to a paired device just as you would to a single device.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device high-availability pair where you want to edit the configuration, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Devices tab.

Step 4 From the Selected Device drop-down list, choose the device you want to modify.
Step 5 Use the sections on the Devices page to make changes to the individual paired device as you would a single
device.

Configuring Individual Device Stacks in a High-Availability Pair

Smart License Classic License Supported Devices Supported Domains Access

N/A Control Firepower 8140, Leaf only Admin/Network

Firepower 8200 Admin
family, Firepower
8300 family

After you configure stacked 8000 Series devices into a high-availability pair, the system limits the stack
attributes that you can edit. You can edit the name of a stack in a paired stack. In addition, you can edit the

Firepower Management Center Configuration Guide, Version 6.3

555
 Classic Device High Availability and Scalability
Configuring Interfaces on a Device in a High-Availability Pair

network configuration of the stack, as described in Configuring Interfaces on a Device in a High-Availability

Pair, on page 556.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device high-availability pair where you want to edit the configuration, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Stacks tab.

Step 4 From the Selected Device drop-down list, choose the stack you want to modify.

Step 5 Next to the General section, click the edit icon ( ).

Step 6 Enter a Name.
Step 7 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring Interfaces on a Device in a High-Availability Pair

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can configure interfaces on individual devices in a 7000 or 8000 Series device high-availability pair.
However, you must also configure an equivalent interface on the peer device in the pair. For paired stacks,
you configure identical interfaces on the primary devices of the stacks. When you configure virtual routers,
you select the stack where you want to configure the routers.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device high-availability pair where you want to configure interfaces, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Interfaces tab.

Step 4 From the Selected Device drop-down list, choose the device you want to modify.
Step 5 Configure interfaces as you would on an individual device.

Firepower Management Center Configuration Guide, Version 6.3

556
 Classic Device High Availability and Scalability
Switching the Active Peer in a Device High-Availability Pair

Related Topics
Virtual Router Configuration, on page 1287

Switching the Active Peer in a Device High-Availability Pair

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Any Admin/Network

Admin

After you establish a 7000 or 8000 Series device high-availability pair, you can manually switch the active
and standby peer devices or stacks.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device high-availability pair where you want to change the active peer, click the Switch Active
Peer icon ( ).
Step 3 You can:
• Click Yes to immediately make the standby peer the active peer in the high-availability pair.
• Click No to cancel and return to the Device Management page.

Placing a High-Availability Peer into Maintenance Mode

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Any Admin/Network

Admin

After you establish a 7000 or 8000 Series device high-availability pair, you can manually trigger failover by
placing one of the peers into maintenance mode to perform maintenance on the devices. In maintenance mode,
the system administratively takes down all interfaces except for the management interface. After maintenance
is completed, you can re-enable the peer to resume normal operation.

Note You should not place both peers in a high-availability pair into maintenance mode at the same time. Doing
so will prevent that pair from inspecting traffic.

Procedure

Step 1 Choose Devices > Device Management.

Firepower Management Center Configuration Guide, Version 6.3

557
 Classic Device High Availability and Scalability
Replacing a Device in a Stack in a High-Availability Pair

Step 2 Next to the peer you want to place in maintenance mode, click the toggle maintenance mode icon ( ).
Step 3 Click Yes to confirm maintenance mode.

What to do next

• When maintenance is complete, click the toggle maintenance mode icon ( ) again to bring the peer out
of maintenance mode.

Replacing a Device in a Stack in a High-Availability Pair

Smart License Classic License Supported Devices Supported Domains Access

N/A Control Firepower 8140, Any Admin/Network

8200 family, 8300 Admin
family

After you place a stack that is a member of a high-availability pair into maintenance mode, you can replace
a secondary device in the stack for another device. You can only select devices that are not currently stacked
or paired. The new device must follow the same guidelines for establishing a device stack.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the stack member you want to place into maintenance mode, click the toggle maintenance mode icon
( ).
Step 3 Click Yes to confirm maintenance mode.

Step 4 Click the replace device icon ( ).

Step 5 Choose the Replacement Device from the drop-down list.
Step 6 Click Replace to replace the device.

Step 7 Click the toggle maintenance mode icon ( ) again to bring the stack immediately out of maintenance mode.
Note You do not need to re-deploy the device configuration.

Device High Availability State Sharing

Device high availability state sharing allows devices or stacks in high-availability pairs to synchronize as
much state as necessary, so that if either device or stack fails, the other peer can take over with no interruption
to traffic flow. Without state sharing, the following features may not fail over properly:
• Strict TCP enforcement

Firepower Management Center Configuration Guide, Version 6.3

558
Classic Device High Availability and Scalability
Device High Availability State Sharing

• Unidirectional access control rules

• Blocking persistence

Note, however, that enabling state sharing slows system performance.

You must configure and enable HA link interfaces on both devices or the primary stacked devices in the
high-availability pair before you can configure high availability state sharing. Firepower 82xx Family and
83xx Family devices require a 10G HA link, while other model devices require a 1G HA link.
You must disable state sharing before you can modify the HA link interfaces.

Note If paired devices fail over, the system terminates all existing SSL-encrypted sessions on the active device.
Even if you establish high availability state sharing, these sessions must be renegotiated on the standby device.
If the server establishing the SSL session supports session reuse and the standby device does not have the
SSL session ID, it cannot renegotiate the session.

Strict TCP Enforcement

When you enable strict TCP enforcement for a domain, the system drops any packets that are out of order on
TCP sessions. For example, the system drops non-SYN packets received on an unestablished connection.
With state sharing, devices in the high-availability pair allow TCP sessions to continue after failover without
having to reestablish the connection, even if strict TCP enforcement is enabled. You can enable strict TCP
enforcement on inline sets, virtual routers, and virtual switches.

Unidirectional Access Control Rules

If you have configured unidirectional access control rules, network traffic may match a different access control
rule than intended when the system reevaluates a connection midstream after failover. For example, consider
if you have a policy containing the following two access control rules:

Rule 1: Allow from 192.168.1.0/24 to 192.168.2.0/24

Rule 2: Block all

Without state sharing, if an allowed connection from 192.168.1.1 to 192.168.2.1 is still active following a
failover and the next packet is seen as a response packet, the system denies the connection. With state sharing,
a midstream pickup would match the existing connection and continue to be allowed.

Blocking Persistence
While many connections are blocked on the first packet based on access control rules or other factors, there
are cases where the system allows some number of packets through before determining that the connection
should be blocked. With state sharing, the system immediately blocks the connection on the peer device or
stack as well.
When establishing state sharing for a high-availability pair, you can configure the following options:

Enabled
Click the check box to enable state sharing. Clear the check box to disable state sharing.

Firepower Management Center Configuration Guide, Version 6.3

559
 Classic Device High Availability and Scalability
Establishing Device High-Availability State Sharing

Minimum Flow Lifetime

Specify the minimum time (in milliseconds) for a session before the system sends any synchronization messages
for it. You can use any integer from 0 to 65535. The system does not synchronize any sessions that have not
met the minimum flow lifetime, and the system synchronizes only when a packet is received for the connection.

Minimum Sync. Interval

Specify the minimum time (in milliseconds) between update messages for a session. You can use any integer
from 0 to 65535. The minimum synchronization interval prevents synchronization messages for a given
connection from being sent more frequently than the configured value after the connection reaches the minimum
lifetime.

Maximum HTTP URL Length

Specify the maximum characters for the URL the system synchronizes between the paired devices. You may
use any integer from 0 to 225.
Related Topics
Configuring HA Link Interfaces, on page 529

Establishing Device High-Availability State Sharing

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Leaf only Admin/Network

Admin

Device high-availability state sharing allows 7000 or 8000 Series devices or stacks in high-availability pairs
to synchronize as much state as necessary, so that if either device or stack fails, the other peer can take over
with no interruption to traffic flow.

Caution Modifying a high-availability state sharing option on a 7000 or 8000 Series device restarts the Snort process
on the primary and secondary devices, temporarily interrupting traffic insepection 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 312 for more information.

Procedure

Step 1 Configure HA link interfaces for each device in the device high-availability pair; see Configuring HA Link
Interfaces, on page 529.
Step 2 Choose Devices > Device Management.

Step 3 Next to the device high-availability pair you want to edit, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 4 In the State Sharing section, click the edit icon ( ).

Firepower Management Center Configuration Guide, Version 6.3

560
 Classic Device High Availability and Scalability
Device High Availability State Sharing Statistics for Troubleshooting

Step 5 Decrease the state sharing values to improve paired peer readiness, or increase the values to allow better
performance.
Note Cisco recommends that you use the default values, unless your deployment presents a good reason
to change them.

Step 6 Click OK to save your changes.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Configuring HA Link Interfaces, on page 529
Snort® Restart Scenarios, on page 311

Device High Availability State Sharing Statistics for

Troubleshooting
The sections below describe the statistics you can view for each device and how you can use them to
troubleshoot your state sharing configuration for 7000 and 8000 Series device high-availability pairs.

Messages Received (Unicast)

Messages received are the number of high availability synchronization messages received from the paired
peer.
The value should be close to the number of messages sent by the peer. During active use, the values may not
match, but should be close. If traffic stops, the values should become stable and the messages received will
match the messages sent.
For troubleshooting, you should view both the messages received and the messages sent, compare the rate of
increase, and make sure the values are close. The sent value on each peer should be incrementing at
approximately the same rate as the received value on the opposite peer.
Contact Support if the received messages stop incrementing or increment slower than the messages sent by
the peer.

Packets Received
The system batches multiple messages into single packets in order to decrease overhead. The Packets Received
counter displays the total number of these data packets, as well as other control packets that have been received
by a device.
The value should be close to the number of packets sent by the peer device. During active use, the values may
not match, but should be close. Because the number of messages received should be close and incrementing
at the same rate as the number of messages sent by the peer, the number of packets received should have the
same behavior.

Firepower Management Center Configuration Guide, Version 6.3

561
 Classic Device High Availability and Scalability
Device High Availability State Sharing Statistics for Troubleshooting

For troubleshooting, you should view both the packets received and the messages sent, compare the rate of
increase, and make sure the values are increasing at the same rate. If the sent value on the paired peer is
incrementing, the received value on the device should also increase at the same rate.
Contact Support if the received packets stop incrementing or increment slower than the messages sent by the
peer.

Total Bytes Received

Total bytes received are the number of bytes that make up the packets received by the peer.
The value should be close to the number of bytes sent by the other peer. During active use, the values may
not match, but should be close.
For troubleshooting, you should view both the total bytes received and the messages sent, compare the rate
of increase, and make sure the values are increasing at the same rate. If the sent value on the paired peer is
incrementing, the received value on the device should also increase at the same rate.
Contact Support if the received bytes stop incrementing or increment slower than the messages sent by the
peer.

Protocol Bytes Received

Protocol bytes received are the number of bytes of protocol overhead received, which includes everything
but the payload of session state synchronization messages.
The value should be close to the number of bytes sent by the peer. During active use, the values may not
match, but should be close.
For troubleshooting, you should view the total bytes received to discover how much actual state data is being
shared in comparison to protocol data. If the protocol data is a large percentage of the data being sent, you
can adjust the minimum sync interval.
Contact Support if the protocol bytes received increment at a similar rate to the total bytes received. Protocol
bytes received should be minimal in relation to the total bytes received.

Messages Sent
Messages sent are the number of high availability synchronization messages sent to the paired peer.
This data is useful in comparison to the number of messages received. During active use, the values may not
match, but should be close.
For troubleshooting, you should view both the messages received and the messages sent, compare the rate of
increase, and make sure the values are close.
Contact Support if the messages sent increment at a similar rate to the total bytes received.

Bytes Sent
Bytes sent are the total number of bytes sent that make up the high availability synchronization messages sent
to the peer.
This data are useful in comparison to the number of messages received. During active use, the values may
not match, but should be close. The number of bytes received on the peer should be close to, but not more
than this value.
Contact Support if the total bytes received is not incrementing at about the same rate as the bytes sent.

Firepower Management Center Configuration Guide, Version 6.3

562
 Classic Device High Availability and Scalability
Viewing Device High Availability State Sharing Statistics

Tx Errors
Tx errors are the number of memory allocation failures the system encounters when trying to allocate space
for messages to be sent to the paired peer.
This value should be zero at all times on both peers. Contact Support if this number is not zero or if the number
steadily increases, which indicates the system has encountered an error where it cannot allocate memory.

Tx Overruns
Tx overruns are the number of times the system attempts and fails to place a message into the transit queue.
This value should be zero at all times on both peers. When the value is not zero or is steadily increasing, it
indicates that the system is sharing too much data across the HA link that cannot be sent quickly enough.
You should increase the HA link MTU if it was previously set below the default value (9918 or 9922). You
can change the minimum flow lifetime and minimum synchronization interval settings to reduce the amount
of data shared across the HA link to prevent the number from incrementing.
Contact Support if this value persists or continues to increase.

Recent Logs
The system log displays the most recent high availability synchronization messages. The log should not display
any ERROR or WARN messages. It should remain comparable between the peers, such as the same number
of sockets being connected.
However, the data displayed may be opposite in some instances, for example, one peer reports that it received
a connection from the other peer and references different IP addresses. The log provides a comprehensive
view of the high availability state sharing connection, and any errors within the connection.
Contact Support if the log displays an ERROR or WARN message, or any message that does not appear to
be purely informational.

Viewing Device High Availability State Sharing Statistics

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Leaf only Admin/Network

Admin

After you establish state sharing, you can view the following information about the configuration in the State
Sharing section of the High Availability page:
• The HA link interface that is being used and its current link state
• Detailed synchronization statistics for troubleshooting issues

The state sharing statistics are primarily counters for different aspects of the high availability synchronization
traffic sent and received, along with some other error counters. In addition, you can view the latest system
logs for each device in the high-availability pair.

Firepower Management Center Configuration Guide, Version 6.3

563
 Classic Device High Availability and Scalability
Separating Device High-Availability Pairs

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device high-availability pair you want to edit, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 In the State Sharing section, click the view statistics icon ( ).
Step 4 Choose a Device to view if your high-availability pair is composed of device stacks.
Step 5 You can:
• Click Refresh to update the statistics.
• Click View to view the latest data log for each device in the high-availability pair.

Separating Device High-Availability Pairs

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Any Admin/Network

Admin

When you separate, or "break," a 7000 or 8000 Series device high-availability pair:
• The active peer (device or stack) retains full deployment functionality
• The standby peer (device or stack) loses its interface configurations and fails over to the active peer,
unless you choose to leave the interface configurations active, in which case the standby peer resumes
normal operation.
• The standby peer always loses the configuration of passive interfaces.
• Any peer in maintenance mode resumes normal operation.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the high-availability pair you want to break, click the Break HA icon ( ).
Step 3 Optionally, check the check box to remove the interface configurations on the standby peer.
This step administratively takes down all interfaces except for the management interface.

Step 4 Click Yes.

Firepower Management Center Configuration Guide, Version 6.3

564
 CHAPTER 26
8000 Series Device Stacking
The following topics describe how to work with Firepower 8000 Series device stacks in the Firepower System:
• About Device Stacks, on page 565
• Device Stack Configuration, on page 567
• Establishing Device Stacks, on page 568
• Editing Device Stacks, on page 569
• Replacing a Device in a Stack, on page 569
• Replacing a Device in a Stack in a High-Availability Pair, on page 570
• Configuring Individual Devices in a Stack, on page 571
• Configuring Interfaces on a Stacked Device, on page 571
• Separating Stacked Devices, on page 572
• Replacing a Device in a Stack, on page 573

About Device Stacks

You can increase the amount of traffic inspected on a network segment by using devices in a stacked
configuration. For each stacked configuration, all devices in the stack must have the same hardware. However,
none, some, or all devices might have an installed malware storage pack. The devices must also be from the
same device family based on the following stacked configurations:
The stacked configuration is supported for Firepower 8140, Firepower 8200 family, Firepower 8300 family
devices.

For the 81xx Family:

• two Firepower 8140s

For the 82xx Family:

• up to four Firepower 8250s
• a Firepower 8260 (a primary device and a secondary device)
• a Firepower 8270 (a primary device with 40G capacity and two secondary devices)
• a Firepower 8290 (a primary device with 40G capacity and three secondary devices)

Firepower Management Center Configuration Guide, Version 6.3

565
 Classic Device High Availability and Scalability
About Device Stacks

For the 83xx Family:

• up to four Firepower 8350s
• up to four AMP8350s
• a Firepower 8360 (a primary device with 40G capacity and a secondary device)
• an AMP8360 (a primary device with 40G capacity and a secondary device)
• a Firepower 8370 (a primary device with 40G capacity and two secondary devices)
• an AMP8370 (a primary device with 40G capacity and two secondary devices)
• a Firepower 8390 (a primary device with 40G capacity and three secondary devices)
• an AMP8390 (a primary device with 40G capacity and three secondary devices)

For more information about stacked configurations, see the Cisco Firepower 8000 Series Getting Started
Guide. For more information about the malware storage pack, see the Firepower System Malware Storage
Pack Guide. Firepower System Malware Storage Pack Guide.

Caution Do not attempt to install a hard drive that was not supplied by Cisco in your device. Installing an unsupported
hard drive may damage the device. Malware storage pack kits are available for purchase only from Cisco,
and are for use only with 8000 Series devices. Contact Support if you require assistance with the malware
storage pack. See the Firepower System Malware Storage Pack Guide for more information.

When you establish a stacked configuration, you combine the resources of each stacked device into a single,
shared configuration.
You designate one device as the primary device, where you configure the interfaces for the entire stack. You
designate the other devices as secondary. Secondary devices must not be currently sensing any traffic and
must not have link on any interface.
Connect the primary device to the network segment you want to analyze in the same way you would configure
a single device. Connect the secondary devices to the primary device using the stacked device cabling
instructions found in the Cisco Firepower 8000 Series Getting Started Guide.
All devices in the stacked configuration must have the same hardware, run the same software version, and
have the same licenses. If the devices are targeted by NAT policies, both the primary and secondary device
must have the same NAT policy. You must deploy updates to the entire stack from the Firepower Management
Center. If an update fails on one or more devices in the stack, the stack enters a mixed-version state. You
cannot deploy policies to or update a stack in a mixed-version state. To correct this state, you can break the
stack or remove individual devices with different versions, update the individual devices, then reestablish the
stacked configuration. After you stack the devices, you can change the licenses only for the entire stack at
once.
After you establish the stacked configuration, the devices act like a single, shared configuration. If the primary
device fails, no traffic is passed to the secondary devices. Health alerts are generated indicating that the stacking
heartbeat has failed on the secondary devices.
If the secondary device in a stack fails, inline sets with configurable bypass enabled go into bypass mode on
the primary device. For all other configurations, the system continues to load balance traffic to the failed
secondary device. In either case, a health alert is generated to indicate loss of link.

Firepower Management Center Configuration Guide, Version 6.3

566
 Classic Device High Availability and Scalability
Device Stack Configuration

You can use a device stack as you would a single device in your deployment, with a few exceptions. If you
have 7000 or 8000 Series devices in a high-availability pair, you cannot stack a device high-availability pair
or a device in a high-availability pair. You also cannot configure NAT on a device stack.

Note If you use eStreamer to stream event data from stacked devices to an external client application, collect the
data from each device and ensure that you configure each device identically. The eStreamer settings are not
automatically synchronized between stacked devices.

In a multidomain deployment, you can only stack devices that belong to the same domain.
Related Topics
About Health Monitoring, on page 239

Device Stack Configuration

You can increase the amount of traffic inspected on a network segment by stacking two Firepower 8140
devices, up to four Firepower 8250s, a Firepower 8260, a Firepower 8270, a Firepower 8290, up to four
Firepower 8350s, a Firepower 8360, a Firepower 8370, or a Firepower 8390 and using their combined resources
in a single, shared, configuration. If you have 7000 or 8000 Series devices in a high-availability pair, you
cannot stack a device high-availability pair or a device in a high-availability pair. However, you can configure
two device stacks into a high-availability pair.
After you establish a device stack, the system treats the devices as a single device on the Device Management
page. Device stacks display the stack icon ( ) in the appliance list.
Removing registration of a device stack from a Firepower Management Center also removes registration from
both devices. You delete stacked devices from the Firepower Management Center as you would a single
managed device; you can then register the stack on another Firepower Management Center. You only need
to register one of the stacked devices on the new Firepower Management Center for the entire stack to appear.
After you establish the device stack, you cannot change which devices are primary or secondary unless you
break and reestablish the stack. However, you can:
• add secondary devices to an existing stack of two or three Firepower 8250s, a Firepower 8260, or a
Firepower 8270 up to the limit of four Firepower 8250s in a stack
• add secondary devices to an existing stack of two or three Firepower 8350s, a Firepower 8360, or a
Firepower 8370 up to the limit of four Firepower 8350s in a stack

For additional devices, the primary device in the stack must have the necessary stacking NetMods for additional
cabled devices. For example, if you have a Firepower 8260 where the primary only has a single stacking
NetMod, you cannot add another secondary device to this stack. You add secondary devices to an existing
stack in the same manner that you initially establish a stacked device configuration.

Firepower Management Center Configuration Guide, Version 6.3

567
 Classic Device High Availability and Scalability
Establishing Device Stacks

Establishing Device Stacks

Smart License Classic License Supported Devices Supported Access
Domains

N/A Any Firepower 8140, 8200 Any Admin/Network

family, 8300 family Admin

All devices in a stack must be of the same hardware model (for example, a Firepower 8140 with another
8140). You can stack a total of four devices (one primary device and up to three secondary devices) in the
8200 family and in the 8300 family.
In a multidomain deployment, all devices in the stack must belong to the same domain.

Before you begin

• Decide which unit will be the primary device.
• Confirm that the units are cabled properly before designating the primary/secondary relationship. For
information about cabling, see the Cisco Firepower 8000 Series Getting Started Guide.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 From the Add drop-down menu, choose Add Stack.
Step 3 From the Primary drop-down list, choose the device that you cabled for primary operation.
Note If you choose a device that is not cabled as the primary device, you cannot perform the next series
of steps.

Step 4 Enter a Name.

Step 5 Click Add to choose the devices you want to include in the stack.
Step 6 From the Slot on Primary Device drop-down list, choose the stacking network module that connects the
primary device to the secondary device.
Step 7 From the Secondary Device drop-down list, choose the device you cabled for secondary operation.
Step 8 From the Slot on Secondary Device drop-down list, choose the stacking network module that connects the
secondary device to the primary device.
Step 9 Click Add.
Step 10 Repeat steps 5 through 9 if you are adding secondary devices to an existing stack of Firepower 8250s, a
Firepower 8260, a Firepower 8270, an existing stack of Firepower 8350s, a Firepower 8360, or a Firepower
8370.
Step 11 Click Stack to establish the device stack or to add secondary devices. Note that this process takes a few
minutes as the process synchronizes system data.

Related Topics
About 7000 and 8000 Series Device High Availability, on page 549

Firepower Management Center Configuration Guide, Version 6.3

568
 Classic Device High Availability and Scalability
Editing Device Stacks

Deleting Devices from the Firepower Management Center, on page 501

Add Devices to the Firepower Management Center, on page 499

Editing Device Stacks

Smart License Classic License Supported Devices Supported Domains Access

N/A Any Firepower 8140, Leaf only Admin/Network

Firepower 8200 Admin
family, Firepower
8300 family

After you establish a device stack, most changes you make to the device configuration also change the
configuration of the entire stack. On the Stack page of the appliance editor, you can make changes to the stack
configuration as on the Device page of a single device.
You can change the display name of the stack, enable and disable licenses, view system and health policies,
and configure advanced settings.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the stacked device where you want to edit the configuration, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Use the sections on the Stack page to make changes to the stacked configuration as you would a single device
configuration.

Replacing a Device in a Stack

Smart License Classic License Supported Devices Supported Domains Access

N/A Any FirePOWER 8140, Any Admin/Network

8200 family, 8300 Admin
family

If the Firepower Management Center cannot communciate with the device, you must connect to the device
and use CLI commands to separate the stack and unregister the device. For more information, see stacking
disable and delete CLI commands in the relevant chapter: Classic Device CLI Configuration Commands, on
page 2718.
To replace a device within a stack:

Firepower Management Center Configuration Guide, Version 6.3

569
 Classic Device High Availability and Scalability
Replacing a Device in a Stack in a High-Availability Pair

Procedure

Step 1 Select the stack with the device to replace and break that stack. For more information, see Separating Stacked
Devices, on page 572.
Step 2 Unregister the device from the Firepower Management Center. For more information, see Deleting Devices
from the Firepower Management Center, on page 501.
Step 3 Register the replacement device to the Firepower Management Center. For more information, see Add Devices
to the Firepower Management Center, on page 499.
Step 4 Create a device stack that includes the replacement deivce. for more information, see Establishing Device
Stacks, on page 568.

Replacing a Device in a Stack in a High-Availability Pair

Smart License Classic License Supported Devices Supported Domains Access

N/A Control Firepower 8140, Any Admin/Network

8200 family, 8300 Admin
family

After you place a stack that is a member of a high-availability pair into maintenance mode, you can replace
a secondary device in the stack for another device. You can only select devices that are not currently stacked
or paired. The new device must follow the same guidelines for establishing a device stack.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the stack member you want to place into maintenance mode, click the toggle maintenance mode icon
( ).
Step 3 Click Yes to confirm maintenance mode.

Step 4 Click the replace device icon ( ).

Step 5 Choose the Replacement Device from the drop-down list.
Step 6 Click Replace to replace the device.

Step 7 Click the toggle maintenance mode icon ( ) again to bring the stack immediately out of maintenance mode.
Note You do not need to re-deploy the device configuration.

Firepower Management Center Configuration Guide, Version 6.3

570
 Classic Device High Availability and Scalability
Configuring Individual Devices in a Stack

Configuring Individual Devices in a Stack

Smart License Classic License Supported Devices Supported Domains Access

N/A Any Firepower 8140, Leaf only Admin/Network

Firepower 8200 Admin
family, Firepower
8300 family

After you establish a device stack, you can still configure some attributes for an individual device within the
stack. You can make changes to a device configured in a stack as you would for a single device. You can
change the display name of a device, view system settings, shut down or restart a device, view health
information, and edit device management settings.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the stacked device where you want to edit the configuration, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Device tab.

Step 4 From the Selected Device drop-down list, choose the device you want to modify.
Step 5 Use the sections on the Devices page to make changes to the individual stacked device as you would a single
device.

Configuring Interfaces on a Stacked Device

Smart License Classic License Supported Devices Supported Domains Access

N/A Any Firepower 8140, Leaf only Admin/Network

Firepower 8200 Admin
family, Firepower
8300 family

With the exception of the management interface, you configure stacked device interfaces on the Interfaces
page of the primary device in the stack. You can choose any device in the stack to configure the management
interface.
The Interfaces page of a Firepower stacked device includes the hardware and interfaces views that you find
on an individual device.

Firepower Management Center Configuration Guide, Version 6.3

571
 Classic Device High Availability and Scalability
Separating Stacked Devices

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the primary stacked device, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Interfaces tab.

Step 4 From the Selected Device drop-down list, choose the device you want to modify.
Step 5 Configure interfaces as you would on an individual device; see Configuring Sensing Interfaces, on page 528.

Related Topics
Management Interfaces, on page 1006

Separating Stacked Devices

Smart License Classic License Supported Devices Supported Domains Access

N/A Any FirePOWER 8140, Any Admin/Network

8200 family, 8300 Admin
family

If you no longer need to use a stacked configuration for your devices, you can break the stack and separate
the devices.

Note If a stacked device fails, or if communication fails between member devices of a stack, you cannot separate
the stacked devices using the Firepower Management Center web interface. In this case, use the auxiliary CLI
command configure stacking disable to remove the stack configuration from each device individually.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device stack you want to break, click the break stack icon ( ).
Tip To remove a secondary device from a stack of three or more Firepower 8250 devices without
breaking the stack, click the remove from stack icon ( ). Removing the secondary device causes
a brief disruption of traffic inspection, traffic flow, or link state as the system reconfigures the stack
for operation without the extra device.

Step 3 Click Yes to separate the device stack.

Firepower Management Center Configuration Guide, Version 6.3

572
 Classic Device High Availability and Scalability
Replacing a Device in a Stack

Replacing a Device in a Stack

Smart License Classic License Supported Devices Supported Domains Access

N/A Any FirePOWER 8140, Any Admin/Network

8200 family, 8300 Admin
family

If the Firepower Management Center cannot communciate with the device, you must connect to the device
and use CLI commands to separate the stack and unregister the device. For more information, see stacking
disable and delete CLI commands in the relevant chapter: Classic Device CLI Configuration Commands, on
page 2718.
To replace a device within a stack:

Procedure

Step 1 Select the stack with the device to replace and break that stack. For more information, see Separating Stacked
Devices, on page 572.
Step 2 Unregister the device from the Firepower Management Center. For more information, see Deleting Devices
from the Firepower Management Center, on page 501.
Step 3 Register the replacement device to the Firepower Management Center. For more information, see Add Devices
to the Firepower Management Center, on page 499.
Step 4 Create a device stack that includes the replacement deivce. for more information, see Establishing Device
Stacks, on page 568.

Firepower Management Center Configuration Guide, Version 6.3

573
 Classic Device High Availability and Scalability
Replacing a Device in a Stack

Firepower Management Center Configuration Guide, Version 6.3

574
PA R T VIII
Firepower Threat Defense Getting Started
• Transparent or Routed Firewall Mode for Firepower Threat Defense, on page 577
• Logical Devices for the Firepower Threat Defense on the Firepower 4100/9300, on page 589
 CHAPTER 27
Transparent or Routed Firewall Mode for
Firepower Threat Defense
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 677 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 577

• Default Settings, on page 585
• Guidelines for Firewall Mode, on page 585
• Set the Firewall Mode, on page 586

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.

Firepower Management Center Configuration Guide, Version 6.3

577
 Firepower Threat Defense Getting Started
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 3: Transparent Firewall Network

Diagnostic Interface
In addition to each Bridge Virtual Interface (BVI) IP address, you can add a separate Diagnostic slot/port
interface that is not part of any bridge group, and that allows only management traffic to the Firepower Threat
Defense device.

Firepower Management Center Configuration Guide, Version 6.3

578
 Firepower Threat Defense Getting Started
Passing Traffic For Routed-Mode Features

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.

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 585 for the
exact number of bridge groups and interfaces supported. If you use more than 2 interfaces per bridge group,

Firepower Management Center Configuration Guide, Version 6.3

579
 Firepower Threat Defense Getting Started
Bridge Groups in Routed Firewall Mode

you can control communication between multiple segments on the same network, and not just between inside
and outside. For example, if you have three inside segments that you do not want to communicate with each
other, you can put each segment on a separate interface, and only allow them to communicate with the outside
interface. Or you can customize the access rules between interfaces to allow only as much access as desired.
The following figure shows two networks connected to the Firepower Threat Defense device, which has two
bridge groups.
Figure 4: 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 Firepower Threat Defense device
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.

Firepower Management Center Configuration Guide, Version 6.3

580
 Firepower Threat Defense Getting Started
Allowing Layer 3 Traffic

Figure 5: 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 581). 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
that you always exempt BPDUs from advanced inspection. To do so, use FlexConfig to configure an EtherType

Firepower Management Center Configuration Guide, Version 6.3

581
 Firepower Threat Defense Getting Started
MAC Address vs. Route Lookups

ACL that trusts BPDUs and exempts them from advanced inspection on each member interface. See FlexConfig
Policies for Firepower Threat Defense, on page 953.
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.

Firepower Management Center Configuration Guide, Version 6.3

582
 Firepower Threat Defense Getting Started
Unsupported Features for Bridge Groups in Transparent Mode

Figure 6: 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 56: 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.

Firepower Management Center Configuration Guide, Version 6.3

583
 Firepower Threat Defense Getting Started
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 57: 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.

Firepower Management Center Configuration Guide, Version 6.3

584
 Firepower Threat Defense Getting Started
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.
• For the Firepower Threat Defense Virtual, 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.
• For IPv4, an IP address for the BVI is required for each bridge group for both management traffic and
for traffic to pass through the Firepower Threat Defense device. IPv6 addresses are supported, but not
required for the BVI.
• 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 4100/9300, data-sharing interfaces are not supported as bridge group members.

Firepower Management Center Configuration Guide, Version 6.3

585
 Firepower Threat Defense Getting Started
Set the Firewall Mode

• 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, EtherChannel interfaces are not supported as 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.

Set the Firewall Mode

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
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 the Trash can icon), confirm, and wait for system to remove the device.
Step 2 Access the FTD device CLI, preferably from the console port.
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.

Firepower Management Center Configuration Guide, Version 6.3

586
Firepower Threat Defense Getting Started
Set the Firewall Mode

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.

Firepower Management Center Configuration Guide, Version 6.3

587
 Firepower Threat Defense Getting Started
Set the Firewall Mode

Firepower Management Center Configuration Guide, Version 6.3

588
 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 729. 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 589
• About Logical Devices, on page 599
• Licenses for Container Instances, on page 607
• Requirements and Prerequisites for Container Instances, on page 608
• Guidelines and Limitations for Logical Devices, on page 609
• Configure Interfaces, on page 611
• Configure Logical Devices, on page 616
• History for Firepower Threat Defense Logical Devices, on page 624

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:

Firepower Management Center Configuration Guide, Version 6.3

589
 Firepower Threat Defense Getting Started
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.

Interface Types
Each interface can be one of the following types:
• Data—Data interfaces cannot be shared between logical devices.
• Data-sharing—Only supported with container instances, these data interfaces can be shared by one or
more logical devices/container instances (FTD-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; see Shared Interface Scalability, on page 591. Shared interfaces
are not supported for bridge group member interfaces (in transparent mode or routed mode), inline sets,
passive interfaces, or failover links.
• Mgmt—Use management interfaces to manage application instances. They 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 information about the separate chassis management interface, see Chassis Management
Interface, on page 589.
Within the FTD application, the physical management interface is shared between the Diagnostic logical
interface and the Management logical interface. The Management logical interface is separate from the
other interfaces on the device. It is used to set up and register the device to the Firepower Management
Center. It uses its own local authentication, IP address, and static routing. See the "Management Interfaces"
section in the Firepower Management Center configuration guide System Configuration chapter.
The Diagnostic logical interface can be configured along with the rest of the data interfaces on the FMC
Devices > Device Management > Interfaces screen. Using the Diagnostic interface is optional. The
Diagnostic interface only allows management traffic, and does not allow through traffic.
• Firepower-eventing—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 Management Interfaces, on page 1006.
Firepower-eventing interfaces can be shared by one or more logical devices to access external hosts;
logical devices cannot communicate over this interface with other logical devices that share the interface.
• Cluster—Special interface type used for a clustered logical device. This type is automatically assigned
to the cluster control link for inter-unit cluster communications. By default, the cluster control link is
automatically created on Port-channel 48.

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.

Firepower Management Center Configuration Guide, Version 6.3

590
 Firepower Threat Defense Getting Started
Shared Interface Scalability

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. Depending on the number of parent interfaces and other deployment decisions, you can create
up to 500 VLAN subinterfaces.
See the following limits for shared interface allocation:
• 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.

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 logical devices.
For example, create a large EtherChannel to bundle all of your like-kind interfaces together, and then
share subinterfaces of that EtherChannel: Port-Channel1.100, 200, and 300 instead of Port-Channel1,
Port-Channel2, and Port-Channel3. 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.
If you do not share the same set of subinterfaces with a group of logical devices, your configuration can
cause more resource usage (more VLAN groups). For example, share Port-Channel1.100 and 200 with
Logical Devices 1, 2, and 3 (one VLAN group) instead of sharing Port-Channel1.100 with Logical Devices
1 and 2, while sharing Port-Channel1.200 with Logical Devices 2 and 3 (two VLAN groups).
2. Fair—Share subinterfaces across parents.
For example, share Port-Channel1.100, Port-Channel2.200, and Port-Channel3.300 instead of
Port-Channel1, Port-Channel2, and Port-Channel3. Although this usage is not as efficient as only sharing
subinterfaces on the same parent, it still takes advantage of VLAN groups.
3. Worst—Share individual parent interfaces (physical or EtherChannel).
This method uses the most forwarding table entries.

Firepower Management Center Configuration Guide, Version 6.3

591
 Firepower Threat Defense Getting Started
Shared Interface Usage Examples

Shared Interface Usage Examples

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 58: Physical/EtherChannel Interfaces and Instances on a Firepower 9300 with Three SM-44s, on
page 592
• Table 59: Subinterfaces on One Parent and Instances on a Firepower 9300 with Three SM-44s, on page
594
• Table 60: Physical/EtherChannel Interfaces and Instances on a Firepower 9300 with One SM-44, on
page 595
• Table 61: Subinterfaces on One Parent and Instances on a Firepower 9300 with One SM-44, on page 597

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 58: 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
• 15 • Instance 2

14: 1 14: 46%

• 14 (1 ea.) • Instance 1-Instance 14

Firepower Management Center Configuration Guide, Version 6.3

592
Firepower Threat Defense Getting Started
Shared Interface Usage Examples

Dedicated Shared Interfaces Number of Instances % Forwarding Table Used

Interfaces

33: 3: 33: 98%

• 11 (1 ea.) •1 • Instance 1-Instance 11
• 11 (1 ea.) •1 • Instance 12-Instance 22
• 11 (1 ea.) •1 • Instance 23-Instance 33

33: 3: 34: 102%

• 11 (1 ea.) •1 • Instance 1-Instance 11 DISALLOWED
• 11 (1 ea.) •1 • Instance 12-Instance 22
• 12 (1 ea.) •1 • Instance 23-Instance 34

30: 1 6: 25%
• 30 (1 ea.) • Instance 1-Instance 6

30: 3: 6: 23%
• 10 (5 ea.) •1 • Instance 1-Instance2
• 10 (5 ea.) •1 • Instance 2-Instance 4
• 10 (5 ea.) •1 • Instance 5-Instance 6

30: 2 5: 28%
• 30 (6 ea.) • Instance 1-Instance 5

30: 4: 5: 26%
• 12 (6 ea.) •2 • Instance 1-Instance2
• 18 (6 ea.) •2 • Instance 2-Instance 5

24: 7 4: 44%
•6 • Instance 1
•6 • Instance 2
•6 • Instance 3
•6 • Instance 4

24: 14: 4: 41%

• 12 (6 ea.) •7 • Instance 1-Instance2
• 12 (6 ea.) •7 • Instance 2-Instance 4

Firepower Management Center Configuration Guide, Version 6.3

593
 Firepower Threat Defense Getting Started
Shared Interface Usage Examples

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 59: 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%

• 168 (4 ea.) • Instance 1-Instance 42

224: 0 14: 27%

• 224 (16 ea.) • Instance 1-Instance 14

14: 1 14: 46%

• 14 (1 ea.) • Instance 1-Instance 14

33: 3: 33: 98%

• 11 (1 ea.) •1 • Instance 1-Instance 11
• 11 (1 ea.) •1 • Instance 12-Instance 22
• 11 (1 ea.) •1 • Instance 23-Instance 33

70: 1 14: 46%

• 70 (5 ea.) • Instance 1-Instance 14

165: 3: 33: 98%

• 55 (5 ea.) •1 • Instance 1-Instance 11
• 55 (5 ea.) •1 • Instance 12-Instance 22
• 55 (5 ea.) •1 • Instance 23-Instance 33

70: 2 14: 46%

• 70 (5 ea.) • Instance 1-Instance 14

165: 6: 33: 98%

• 55 (5 ea.) •2 • Instance 1-Instance 11
• 55 (5 ea.) •2 • Instance 12-Instance 22
• 55 (5 ea.) •2 • Instance 23-Instance 33

Firepower Management Center Configuration Guide, Version 6.3

594
Firepower Threat Defense Getting Started
Shared Interface Usage Examples

Dedicated Shared Subinterfaces Number of Instances % Forwarding Table Used

Subinterfaces

70: 10 14: 46%

• 70 (5 ea.) • Instance 1-Instance 14

165: 30: 33: 102%

• 55 (5 ea.) • 10 • Instance 1-Instance 11 DISALLOWED
• 55 (5 ea.) • 10 • Instance 12-Instance 22
• 55 (5 ea.) • 10 • Instance 23-Instance 33

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 60: Physical/EtherChannel Interfaces and Instances on a Firepower 9300 with One SM-44

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
• 15 • Instance 2

14: 1 14: 46%

• 14 (1 ea.) • Instance 1-Instance 14

14: 2: 14: 37%

• 7 (1 ea.) •1 • Instance 1-Instance 7
• 7 (1 ea.) •1 • Instance 8-Instance 14

Firepower Management Center Configuration Guide, Version 6.3

595
 Firepower Threat Defense Getting Started
Shared Interface Usage Examples

Dedicated Shared Interfaces Number of Instances % Forwarding Table Used

Interfaces

32: 1 4: 21%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3
•8 • Instance 4

32: 2 4: 20%
• 16 (8 ea.) • Instance 1-Instance 2
• 16 (8 ea.) • Instance 3-Instance 4

32: 2 4: 25%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3
•8 • Instance 4

32: 4: 4: 24%
• 16 (8 ea.) •2 • Instance 1-Instance 2
• 16 (8 ea.) •2 • Instance 3-Instance 4

24: 8 3: 37%
•8 • Instance 1
•8 • Instance 2
•8 • Instance 3

10: 10 5: 69%
• 10 (2 ea.) • Instance 1-Instance 5

10: 20: 5: 59%

• 6 (2 ea.) • 10 • Instance 1-Instance 3
• 4 (2 ea.) • 10 • Instance 4-Instance 5

14: 10 7: 109%
• 12 (2 ea.) • Instance 1-Instance 7 DISALLOWED

Firepower Management Center Configuration Guide, Version 6.3

596
Firepower Threat Defense Getting Started
Shared Interface Usage Examples

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 61: Subinterfaces on One Parent and Instances on a Firepower 9300 with One SM-44

Dedicated Shared Subinterfaces Number of Instances % Forwarding Table Used

Subinterfaces

112: 0 14: 17%

• 112 (8 ea.) • Instance 1-Instance 14

224: 0 14: 17%

• 224 (16 ea.) • Instance 1-Instance 14

14: 1 14: 46%

• 14 (1 ea.) • Instance 1-Instance 14

14: 2: 14: 37%

• 7 (1 ea.) •1 • Instance 1-Instance 7
• 7 (1 ea.) •1 • Instance 8-Instance 14

112: 1 14: 46%

• 112 (8 ea.) • Instance 1-Instance 14

112: 2: 14: 37%

• 56 (8 ea.) •1 • Instance 1-Instance 7
• 56 (8 ea.) •1 • Instance 8-Instance 14

112: 2 14: 46%

• 112 (8 ea.) • Instance 1-Instance 14

112: 4: 14: 37%

• 56 (8 ea.) •2 • Instance 1-Instance 7
• 56 (8 ea.) •2 • Instance 8-Instance 14

140: 10 14: 46%

• 140 (10 ea.) • Instance 1-Instance 14

Firepower Management Center Configuration Guide, Version 6.3

597
 Firepower Threat Defense Getting Started
Viewing Shared Interface Resources

Dedicated Shared Subinterfaces Number of Instances % Forwarding Table Used

Subinterfaces

140: 20: 14: 37%

• 70 (10 ea.) • 10 • Instance 1-Instance 7
• 70 (10 ea.) • 10 • Instance 8-Instance 14

Viewing Shared Interface Resources

To view forwarding table and VLAN group usage, enter the show detail command under scope
fabric-interconnect. For example:

Firepower# scope fabric-interconnect

DFirepower /fabric-interconnect # show detail

Fabric Interconnect:
ID: A
Product Name: Cisco FPR9K-SUP
PID: FPR9K-SUP
VID: V02
Vendor: Cisco Systems, Inc.
Serial (SN): JAD104807YN
HW Revision: 0
Total Memory (MB): 16185
OOB IP Addr: 10.10.5.14
OOB Gateway: 10.10.5.1
OOB Netmask: 255.255.255.0
OOB IPv6 Address: ::
OOB IPv6 Gateway: ::
Prefix: 64
Operability: Operable
Thermal Status: Ok
Ingress VLAN Group Entry Count (Current/Max): 0/500
Switch Forwarding Path Entry Count (Current/Max): 16/1021
Current Task 1:
Current Task 2:
Current Task 3:

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.

Firepower Management Center Configuration Guide, Version 6.3

598
 Firepower Threat Defense Getting Started
About Logical Devices

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 must install the same application instance type (ASA or FTD) on all modules
in the chassis; different types are not supported at this time. Note that modules can run different versions of
an application instance type.

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.
• 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 module application instances belong to a single
logical device.

Note For the Firepower 9300, all modules must belong to the cluster. You cannot create
a standalone logical device on one security module and then create a cluster using
the remaining 2 security modules.

Container Instances and Native Instances

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; it is not supported for the ASA.

Firepower Management Center Configuration Guide, Version 6.3

599
 Firepower Threat Defense Getting Started
Container Instance Interfaces

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. See Shared Interface Scalability, on page 591 and Add a VLAN
Subinterface for Container Instances, on page 614.

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
instance without unique MAC addresses. You can also set the MAC addresses manually when you
configure each interface within the application. However, 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.

Note If the destination MAC address is a multicast or broadcast MAC address, the packet is duplicated and delivered
to each instance.

Classification Examples
The following figure shows multiple instances sharing an outside interface. The classifier assigns the packet
to Instance C because Instance C includes the MAC address to which the router sends the packet.

Firepower Management Center Configuration Guide, Version 6.3

600
Firepower Threat Defense Getting Started
Classification Examples

Figure 7: 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.

Firepower Management Center Configuration Guide, Version 6.3

601
 Firepower Threat Defense Getting Started
Classification Examples

Figure 8: 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.

Firepower Management Center Configuration Guide, Version 6.3

602
Firepower Threat Defense Getting Started
Classification Examples

Figure 9: 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.

Firepower Management Center Configuration Guide, Version 6.3

603
 Firepower Threat Defense Getting Started
Cascading Container Instances

Figure 10: 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.

Firepower Management Center Configuration Guide, Version 6.3

604
 Firepower Threat Defense Getting Started
Typical Multi-Instance Deployment

Figure 11: 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 management 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.

Firepower Management Center Configuration Guide, Version 6.3

605
 Firepower Threat Defense Getting Started
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.

Note 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.

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:

Firepower Management Center Configuration Guide, Version 6.3

606
 Firepower Threat Defense Getting Started
Container Instance Resource Management

A24D.00zz.zzzz
For a prefix of 1009 (03F1), the MAC address is:
A2F1.03zz.zzzz

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 608. To add a resource profile, see Add a Resource Profile
for Container Instances, on page 616.

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.
Each unit must use the same resource profile attributes.
Each High Availability pair requires a dedicated failover link, and you cannot use a data-sharing interface.
We recommend that you create subinterfaces on a parent interface, and assign a subinterface for each instance
to use as a failover link.

Note Clustering is not supported.

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
704.

For example:

Firepower Management Center Configuration Guide, Version 6.3

607
 Firepower Threat Defense Getting Started
Requirements and Prerequisites for Container Instances

Table 62: 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 63: Total Number of Licenses

Base URL Filtering Malware Threat

3 2 3 2

Requirements and Prerequisites for Container Instances

Supported Application Types
• Firepower Threat Defense

FTD: 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 64: 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 4120 3 46 101 GB 125.6 GB

Firepower 4140 7 70 222 GB 311.8 GB

Firepower 4150 7 86 222 GB 311.8 GB

Firepower 9300 SM-24 security 7 46 226 GB 656.4 GB

module

Firepower Management Center Configuration Guide, Version 6.3

608
 Firepower Threat Defense Getting Started
Guidelines and Limitations for Logical Devices

Model Max. Container Available CPU Cores Available RAM Available Disk Space
Instances

Firepower 9300 SM-36 security 11 70 222 GB 640.4 GB

module

Firepower 9300 SM-44 security 14 86 218 GB 628.4 GB

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.

Guidelines and Limitations for Logical Devices

See the following sections for guidelines and limitations.

Guidelines and Limitations for Firepower Interfaces

VLAN Subinterfaces
• You can create between 250 and 500 subinterfaces per chassis using up to 500 VLAN IDs, depending
on your network deployment.
• Subinterfaces are supported on data or data-sharing type interfaces only.
• 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.

• 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
• Maximum 14 instances per shared interface. For example, you can allocate Ethernet1/1 to Instance1
through Instance14.

Firepower Management Center Configuration Guide, Version 6.3

609
 Firepower Threat Defense Getting Started
Guidelines and Limitations for Firepower Interfaces

• Maximum 10 shared interfaces per instance. For example, you can allocate Ethernet1/1.1 through
Ethernet1/1.10 to Instance1.
• You cannot use a data-sharing interface with a native instance.
• 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.
• 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.

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. See Automatic MAC Addresses
for Container Instance Interfaces, on page 606.

Firepower Management Center Configuration Guide, Version 6.3

610
 Firepower Threat Defense Getting Started
General Guidelines and Limitations

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.
• The two units in a High Availability Failover configuration must:
• 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.

• For more information, see High Availability System Requirements, on page 703.

Multi-Instance and Context Mode

• Multiple context mode is only supported on the ASA.
• Multi-instance capability with container instances is only available for the FTD.
• For container instances, you can assign each shared interface to up to 14 container instances.
• For a given container instance, you can assign up to 10 shared interfaces.
• 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:
• SSL hardware acceleration
• Clustering
• Radware DefensePro link decorator
• FMC backup and restore
• FMC UCAPL/CC mode

Configure Interfaces
By default, physical interfaces are disabled. You can enable interfaces, add EtherChannels, add VLAN
subinterfaces, and edit interface properties.

Firepower Management Center Configuration Guide, Version 6.3

611
 Firepower Threat Defense Getting Started
Enable or Disable an Interface

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 ( ) so that it changes to the enabled slider ( ).
Click Yes to confirm the change. The corresponding interface in the visual representation changes from gray
to green.

Step 3 To disable the interface, click the enbled slider ( ) so that it changes to the disabled slider ( ).
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

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 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: Data, Data-sharing, Mgmt, Firepower-eventing, or 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.

Firepower Management Center Configuration Guide, Version 6.3

612
 Firepower Threat Defense Getting Started
Add an EtherChannel (Port Channel)

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.

Add an EtherChannel (Port Channel)

An EtherChannel (also known as a port channel) can include up to 16 member interfaces of the same type.
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.
When the Firepower 4100/9300 chassis creates an EtherChannel, the EtherChannel stays in a Suspended
state 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
state.

Procedure

Step 1 Choose Interfaces to open the Interfaces page.

Firepower Management Center Configuration Guide, Version 6.3

613
 Firepower Threat Defense Getting Started
Add a VLAN Subinterface for Container Instances

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 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 configure an EtherChannel with a different
ID and choose the Cluster type for the interface. Do not assign any interfaces to the Cluster EtherChannel.

Step 4 To enable the port channel, check the Enable check box. To disable the port channel, uncheck the Enable
check box.
Step 5 Choose the interface Type: Data, Data-sharing, Mgmt, Firepower-eventing, or Cluster.
Do not choose the Cluster type unless you want to use this port-channel as the cluster control link instead of
the default.

Step 6 Set the Admin Speed of the member interfaces from the drop-down list.
Step 7 For Data or Data-sharing interfaces, choose the LACP port-channel Mode, Active or On.
For non-Data or non-Data-sharing interfaces, the mode is always active.

Step 8 Set the Admin Duplex, Full Duplex or Half Duplex.

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 interfaces of the same type and
speed.
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.
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.
For native instances, you can create VLAN subinterfaces within the application only. For container instances,
you can also create VLAN subinterfaces inside the application on interfaces that do not have FXOS VLAN
subinterfaces defined, and these 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,

Firepower Management Center Configuration Guide, Version 6.3

614
Firepower Threat Defense Getting Started
Add a VLAN Subinterface for Container Instances

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:

Procedure

Step 1 Choose Interfaces to open the All Interfaces tab.

Firepower Management Center Configuration Guide, Version 6.3

615
 Firepower Threat Defense Getting Started
Configure Logical Devices

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.
Step 3 Choose the interface Type: Data or Data-sharing.
Subinterfaces are supported on data or data-sharing type interfaces only. 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 729.

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.
• You cannot specify 8 cores due to internal architecture.
• You can assign cores as an even number (6, 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 608.

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.

Firepower Management Center Configuration Guide, Version 6.3

616
 Firepower Threat Defense Getting Started
Add a Standalone Firepower Threat Defense

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, 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 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. You cannot specify 8 cores.

Step 3 Click OK.

Add a Standalone Firepower Threat Defense

Standalone logical devices work either alone or in a High Availability pair. On multiple module devices, like
the Firepower 9300, 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 must install the same application instance type (ASA
or FTD) on all modules in the chassis; different types are not supported at this
time. Note that modules can run different versions of an application instance type.

• 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 interface that is used
only for chassis management (and that appears at the top of the Interfaces tab as MGMT).
• You must also configure at least one Data type interface. Optionally, you can also create a
firepower-eventing interface to carry all event traffic (such as web events). See Interface Types, on page
590 for more information.

Firepower Management Center Configuration Guide, Version 6.3

617
 Firepower Threat Defense Getting Started
Add a Standalone Firepower Threat Defense

• 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 616.
• 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 Security Module/Engine 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.

Procedure

Step 1 Choose Logical Devices.

The Logical Devices page shows a list of logical devices on the chassis.

Step 2 Click Add Device.

The Add Device dialog box appears.

Step 3 For the Device Name, provide a name for the logical device.
This name is used by the Firepower 4100/9300 chassis supervisor to configure management settings and to
assign interfaces; it is not the device name used in the security module/engine configuration.

Step 4 For the Template, choose Cisco Firepower Threat Defense.

Step 5 Choose the Image Version.
Step 6 Choose the Instance Type, Container or Native.
Step 7 For the Device Mode, click the Standalone radio button.
Step 8 Click OK.
You see the Provisioning - device name window.

Step 9 Expand the Data Ports area, and click each interface that you want to assign to the device.
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: . 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 10 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 change most values in the application
CLI configuration.

Step 11 On the General Information tab, complete the following:

a) (On multiple module devices, like the Firepower 9300) Under Security Module Selection click the
security module that you want to use for this logical device.
b) Choose the Management Interface.

Firepower Management Center Configuration Guide, Version 6.3

618
 Firepower Threat Defense Getting Started
Add a High Availability Pair

c) 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, if you assign a different-sized resource profile,
be sure to make all members the same size as soon as possible.
d) Choose the management interface Address Type, IPv4 only, IPv6 only, or IPv4 and IPv6.
e) Configure the Management IP address.
f) Enter a Network Mask or Prefix Length.
g) Enter a Network Gateway address.
Step 12 On the Settings tab, complete the following:
a) In the Registration Key field, enter the key to be shared between Firepower Management Center and the
device during registration.
b) In the Password field, enter a password for the device.
c) In the Firepower Management Center IP field, enter the IP address of the managing Firepower
Management Center.
d) Permit Expert mode from FTD SSH sessions, Yes or No. Expert Mode provides FTD shell access for
advanced troubleshooting.
If you choose Yes for this option, then users who access the container instance directly from an SSH
sesssion can enter Expert Mode. If you choose No, then only users who access the container instance from
the FXOS CLI can enter Expert Mode. We recommend choosing No to increase isolation between instances.
Use Expert Mode only if a documented procedure tells you it is required, or if the Cisco Technical
Assistance Center asks you to use it. To enter this mode, use the expert command in the FTD CLI.
e) In the Search Domains field, enter a comma-separated list of search domains for the device.
f) Choose the Firewall Mode, Transparent or Routed.
g) In the DNS Servers field, enter a comma-separated list of DNS servers for the device to use.
h) In the Fully Qualified Hostname field, enter a fully qualified name for the Threat Defense device.
i) Choose the Eventing Interface on which Firepower events should be sent. If not specified, the management
interface will be used.
To specify an interface to use for Firepower events, you must configure an interface as a firepower-eventing
interface. For more information, see About Firepower Interfaces, on page 589.

Step 13 On the Agreement tab, read and accept the end user license agreement (EULA).
Step 14 Click OK to close the configuration dialog box.
Step 15 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 specified security module/engine.

Add a High Availability Pair

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.

Firepower Management Center Configuration Guide, Version 6.3

619
 Firepower Threat Defense Getting Started
Change an Interface on a Firepower Threat Defense Logical Device

Before you begin

• The two units in a High Availability Failover configuration must:
• 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.

• For High Availability system requirements, see High Availability System Requirements, on page 703.

Procedure

Step 1 Each logical device should be on a separate chassis; intra-chassis High Availability for the Firepower 9300
is not recommended and may not be supported.
Step 2 Allocate the same interfaces to each logical device.
Step 3 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 4 Enable High Availability on the logical devices. See High Availability for Firepower Threat Defense, on page
703.
Step 5 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.

Change an Interface on a Firepower Threat Defense Logical Device

You can allocate or unallocate an interface, or replace a management interface on a Firepower Threat Defense
logical device. You can then sync the interface configuration in the Firepower Management Center.

Before you begin

• Configure your interfaces, and add any EtherChannels according to Configure a Physical Interface, on
page 612 and Add an EtherChannel (Port Channel), on page 613.
• You can edit the membership of an allocated EtherChannel without affecting the logical device or requiring
a sync on the Firepower Management Center.

Firepower Management Center Configuration Guide, Version 6.3

620
Firepower Threat Defense Getting Started
Change an Interface on a Firepower Threat Defense Logical Device

• 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 Firepower Threat Defense
device reboots (management interface changes cause a reboot), and you sync the configuration in the
Firepower Management Center, you can add the (now unallocated) management interface to the
EtherChannel as well.
• For clustering or High Availability, make sure you add or remove the interface on all units before you
sync the configuration in the Firepower Management Center. We recommend that you make the interface
changes on the slave/standby unit(s) first, and then on the master/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 Unallocate a data interface by de-selecting the interface in the Data Ports area.
Step 4 Allocate a new data interface by selecting the interface in the Data Ports area.
Step 5 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/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 6 Click Save.

Step 7 Log into the Firepower Management Center.

Step 8 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.
Step 9 Click the Sync Interfaces from device button on the top left of the Interfaces tab.
Step 10 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Firepower Management Center Configuration Guide, Version 6.3

621
 Firepower Threat Defense Getting Started
Connect to the Console of the Application

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.
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
If you have multiple application instances for an application type, you must specify the name of the instance.
To view the instance names, enter the command without a name.
Example:

Firepower-module1> connect ftd

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

You might want to use the FXOS module CLI for troubleshooting purposes.

Step 4 Return to the supervisor level of the FXOS CLI.

Exit the console:
a) Enter ~
You exit to the Telnet application.

Firepower Management Center Configuration Guide, Version 6.3

622
Firepower Threat Defense Getting Started
Connect to the Console of the Application

b) To exit the Telnet application, enter:

telnet>quit

Exit the Telnet session:

a) Enter Ctrl-], .

Example
The following example connects to an ASA on security module 1 and then exits back to the supervisor
level of the FXOS CLI.
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>connect asa
asa> ~
telnet> quit
Connection closed.
Firepower#

Firepower Management Center Configuration Guide, Version 6.3

623
 Firepower Threat Defense Getting Started
History for Firepower Threat Defense Logical Devices

History for Firepower Threat Defense Logical Devices

Feature Version Details

Multi-instance capability for Firepower 6.3.0

Threat Defense on the Firepower 4100/9300

Firepower Management Center Configuration Guide, Version 6.3

624
 Firepower Threat Defense Getting Started
History for Firepower Threat Defense Logical Devices

Feature Version Details

You can now deploy multiple logical
devices, each with a Firepower Threat
Defense container instance, on a single
security engine/module. 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

New/Modified Firepower Chassis Manager

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

Firepower Management Center Configuration Guide, Version 6.3

625
 Firepower Threat Defense Getting Started
History for Firepower Threat Defense Logical Devices

Feature Version Details

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
Supported platforms: Firepower 4100/9300

Cluster control link customizable IP 6.3.0 By default, the cluster control link uses the
Address for the Firepower 4100/9300 127.2.0.0/16 network. You 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
Supported platforms: Firepower 4100/9300

Support for data EtherChannels in On mode 6.3.0 You can now set data and data-sharing
EtherChannels to either Active LACP mode
or to On mode. Other types of
EtherChannels only support Active mode.
New/Modified Firepower Chassis Manager
screens:
• Interfaces > All Interfaces > Edit
Port Channel > Mode

New/Modified FXOS commands: set

port-channel-mode
Supported platforms: Firepower 4100/9300

Firepower Management Center Configuration Guide, Version 6.3

626
 Firepower Threat Defense Getting Started
History for Firepower Threat Defense Logical Devices

Feature Version Details

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

Inter-chassis clustering for 6 FTD modules 6.2.0 You can now enable inter-chassis clustering
for the FTD. You can include up to 6
modules in up to 6 chassis.
New/modified Firepower Chassis Manager
screens:
• Logical Devices > Configuration

Supported platforms: Firepower 4100/9300

Hardware bypass support on the Firepower 6.1.0 Hardware Bypass ensures that traffic
4100/9300 for supported network modules continues to flow between an inline
interface pair during a power outage. This
feature can be used to maintain network
connectivity in the case of software or
hardware failures.
New/Modified screens:
• Devices > Device Management >
Interfaces > Edit Physical Interface

Supported platforms: Firepower 4100/9300

Inline set link state propagation support for 6.1.0 When you configure an inline set in the
the FTD FTD application and enable link state
propagation, the FTD sends inline set
membership to the FXOS chassis. Link
state propagation means that the chassis
automatically brings down the second
interface in the inline interface pair when
one of the interfaces in an inline set goes
down.
New/Modified FXOS commands: show
fault |grep link-down, show interface
detail
Supported platforms: Firepower 4100/9300

Firepower Management Center Configuration Guide, Version 6.3

627
 Firepower Threat Defense Getting Started
History for Firepower Threat Defense Logical Devices

Feature Version Details

Support for intra-chassis clustering on the 6.0.1 The Firepower 9300 supports intra-chassis
FTD on the Firepower 9300 clustering with the FTD application.
New/Modified Firepower Chassis Manager
screens:
• 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
Supported platforms: Firepower 4100/9300

Firepower Management Center Configuration Guide, Version 6.3

628
PA R T IX
Firepower Threat Defense Interfaces and Device
Settings
• Interface Overview for Firepower Threat Defense, on page 631
• Regular Firewall Interfaces for Firepower Threat Defense, on page 637
• Inline Sets and Passive Interfaces for Firepower Threat Defense, on page 677
• DHCP and DDNS Services for Threat Defense, on page 685
• Quality of Service (QoS) for Firepower Threat Defense, on page 693
 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 631
• Interface Mode and Types, on page 632
• Security Zones and Interface Groups, on page 633
• Auto-MDI/MDIX Feature, on page 633
• Default Settings for Interfaces, on page 634
• Enable the Physical Interface and Configure Ethernet Settings, on page 634
• Sync Interface Changes with the Firepower Management Center, on page 636

Management/Diagnostic Interface
The physical management interface is shared between the Diagnostic logical interface and the Management
logical interface.

Management Interface
The Management logical interface is separate from the other interfaces on the device. It is used to set up and
register the device to the Firepower Management Center. It uses its own IP address and static routing. You
can configure its settings at the CLI using the configure network command. If you change the IP address at
the CLI after you add it to the Firepower Management Center, you can match the IP address in the Firepower
Management Center in the Devices > Device Management > Devices > Management area.

Diagnostic Interface
The Diagnostic logical interface can be configured along with the rest of the data interfaces on the Devices >
Device Management > Interfaces screen. Using the Diagnostic interface is optional (see the routed and
transparent mode deployments for scenarios). The Diagnostic interface only allows management traffic, and
does not allow through traffic. It does not support SSH; you can SSH to data interfaces or to the Management
interface only. The Diagnostic interface is useful for SNMP or syslog monitoring.

Firepower Management Center Configuration Guide, Version 6.3

631
 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 577 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
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. 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.

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.

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 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.
With tap mode, the device is deployed inline, but instead of the packet flow passing through the device,
a copy of each packet is sent to the device and the network traffic flow is undisturbed. However, 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 devices that are deployed inline. For example, you can set up the cabling between
the device and the network as if the device were inline and analyze the kinds of intrusion events the
device 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 device

Firepower Management Center Configuration Guide, Version 6.3

632
 Firepower Threat Defense Interfaces and Device Settings
Security Zones and Interface Groups

inline, you can disable tap mode and begin dropping suspicious traffic without having to reconfigure the
cabling between the device 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 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. 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 device is in routed firewall mode.

Security Zones and Interface Groups

Each interface must 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. 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 379. You can create security zones and interface groups on the Objects page. You can also add a zone
when you are configuring the interface. You can only add interfaces to the correct zone type for your interface,
either Passive, Inline, Routed, or Switched zone types.
The Diagnostic/Management interface does not belong to a zone or interface group.

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.

Auto-MDI/MDIX Feature
For RJ-45 interfaces, the default auto-negotiation setting also includes the Auto-MDI/MDIX feature.
Auto-MDI/MDIX eliminates the need for crossover cabling by performing an internal crossover when a
straight cable is detected during the auto-negotiation phase. Either the speed or duplex must be set to
auto-negotiate to enable Auto-MDI/MDIX for the interface. If you explicitly set both the speed and duplex
to a fixed value, thus disabling auto-negotiation for both settings, then Auto-MDI/MDIX is also disabled. For
Gigabit Ethernet, when the speed and duplex are set to 1000 and full, then the interface always auto-negotiates;
therefore Auto-MDI/MDIX is always enabled and you cannot disable it.

Firepower Management Center Configuration Guide, Version 6.3

633
 Firepower Threat Defense Interfaces and Device Settings
Default Settings for Interfaces

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.

Enable the Physical Interface and Configure Ethernet Settings

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

634
Firepower Threat Defense Interfaces and Device Settings
Enable the Physical Interface and Configure Ethernet Settings

Note For the Firepower 4100/9300, you configure basic interface settings in FXOS. See Configure a Physical
Interface, on page 612 for more information.

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 the Sync Interfaces from device button on the top left of the Interfaces tab.

Procedure

Step 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) 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 the Hardware Configuration tab.
• Duplex—Choose Full, Half, or Auto. Auto is the default when the interface supports it. For example,
you cannot select Auto for the SFP interfaces on a Firepower 2100 series device.
• Speed—Choose 10, 100, 1000, or Auto. Auto is the default. The type of interface limits the options you
can select. For example, on Firepower 2100 series devices, you can select 10, 100, or 1000 (1Gbps) for
GigabitEthernet ports, and 1000 or 10000 (10 Gpbs) for SFP ports. Note that the SFP interfaces on
Firepower 2100 series devices do not support Auto.

Step 6 In the Mode drop-down list, choose one of the following:.

• 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 click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Firepower Management Center Configuration Guide, Version 6.3

635
 Firepower Threat Defense Interfaces and Device Settings
Sync Interface Changes with the Firepower Management Center

SyncInterfaceChangeswiththeFirepowerManagementCenter
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

Interface configuration changes on the device can cause the FMC and the device to get out of sync. The FMC
can detect interface changes by one of the following methods:
• Event sent from the device
• Sync when you deploy from the FMC
If the FMC detects interface changes when it attempts to deploy, the deploy will fail. You must first
accept the interface changes.
• Manual sync

When the FMC detects changes, the Interface tab shows status icons (removed, changed, or added) to the
left of each interface icon.
This procedure describes how to manually sync device changes if required and how to save 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.

Procedure

Step 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.
Step 2 If required, click the Sync Device button on the top left of the Interfaces tab.
Step 3 After the changes are detected, you will see a red banner on the Interfaces tab indicating that the interface
configuration has changed. Click the Click to know more link to view the interface changes.
Step 4 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.

Step 5 Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Firepower Management Center Configuration Guide, Version 6.3

636
 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 611.

• Configure EtherChannel and Redundant Interfaces, on page 637

• Configure VLAN Subinterfaces and 802.1Q Trunking, on page 645
• Configure Routed and Transparent Mode Interfaces, on page 647
• Configure Advanced Interface Settings, on page 663
• History for Regular Firewall Interfaces for Firepower Threat Defense, on page 674

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),
on page 613 for more information. Redundant interfaces are not supported.

About EtherChannels and Redundant Interfaces

This section describes EtherChannels and Redundant Interfaces.

Redundant Interfaces
A logical redundant interface consists of a pair of physical interfaces: an active and a standby interface. When
the active interface fails, the standby interface becomes active and starts passing traffic. You can configure a
redundant interface to increase the Firepower Threat Defense device reliability.
You can configure up to 8 redundant interface pairs.

Firepower Management Center Configuration Guide, Version 6.3

637
 Firepower Threat Defense Interfaces and Device Settings
Redundant Interface MAC Address

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.

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.

Channel Group Interfaces

Each channel group can have up to 16 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. Note that for interfaces that you can configure to use either the
RJ-45 or SFP connector, you can include both RJ-45 and SFP interfaces in the same EtherChannel.
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 Firepower Threat Defense device 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 Firepower Threat Defense device 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.
Figure 12: Connecting to a VSS/vPC

Firepower Management Center Configuration Guide, Version 6.3

638
 Firepower Threat Defense Interfaces and Device Settings
Link Aggregation Control Protocol

If you use the Firepower Threat Defense device in an Active/Standby failover deployment, then you need to
create separate EtherChannels on the switches in the VSS/vPC, one for each Firepower Threat Defense device.
On each Firepower Threat Defense device, a single EtherChannel connects to both switches. Even if you
could group all switch interfaces into a single EtherChannel connecting to both Firepower Threat Defense
device (in this case, the EtherChannel will not be established because of the separate Firepower Threat Defense
device system IDs), a single EtherChannel would not be desirable because you do not want traffic sent to the
standby Firepower Threat Defense device.
Figure 13: 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:
• 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.
• 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 Firepower Threat Defense device 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.

Firepower Management Center Configuration Guide, Version 6.3

639
 Firepower Threat Defense Interfaces and Device Settings
EtherChannel MAC Address

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, EtherChannels are not supported as 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.
• 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.
• 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 either shut down the EtherChannel while you
make changes, or temporarily disable High Availability; either action prevents High Availability from
occurring for the duration.

Model Support
• EtherChannels are supported on Firepower Threat Defense device appliances only; they are not supported
on the Firepower Threat Defense Virtual.
• For the Firepower 4100/9300 chassis, you configure EtherChannels in FXOS, not in the Firepower Threat
Defense device OS.
• Redundant interfaces are not supported on the Firepower 2100, Firepower 4100/9300 chassis.

Firepower Management Center Configuration Guide, Version 6.3

640
Firepower Threat Defense Interfaces and Device Settings
Guidelines for EtherChannels and Redundant Interfaces

Redundant Interfaces
• You can configure up to 8 redundant interface pairs.
• All Firepower Threat Defense device 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 Firepower Threat Defense
device 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.

EtherChannels
• EtherChannels are supported on Firepower Threat Defense device appliances only; they are not supported
on the Firepower Threat Defense Virtual.
• You can configure up to 48 EtherChannels.
• Each channel group can have up to 16 active interfaces. For switches that support only 8 active interfaces,
you can assign up to 16 interfaces to a channel group: while only eight 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 and speed. The first interface added to the
channel group determines the correct type and speed. Note that for interfaces that you can configure to
use either the RJ-45 or SFP connector, you can include both RJ-45 and SFP interfaces on the same
network module in the same EtherChannel.
• The device to which you connect the Firepower Threat Defense device EtherChannel must also support
802.3ad EtherChannels; for example, you can connect to the Catalyst 6500 switch or Cisco Nexus 7000
switch.
• The Firepower Threat Defense device 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 Firepower Threat Defense device will drop the tagged LACPDUs. Be sure to disable native
VLAN tagging on the neighboring switch.
• In Cisco IOS software versions earlier than 15.1(1)S2, the Firepower Threat Defense device did not
support connecting an EtherChannel to a switch stack. With default switch settings, if the Firepower
Threat Defense device EtherChannel is connected cross stack, and if the master 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 Firepower Threat Defense device 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

Firepower Management Center Configuration Guide, Version 6.3

641
 Firepower Threat Defense Interfaces and Device Settings
Configure a Redundant Interface

an EtherChannel interface. You can, however, configure both types on the Firepower Threat Defense
device if they do not use the same physical interfaces.

Configure a Redundant Interface

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 4100/9300.

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.

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 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.
Step 2 Enable the member interfaces according to Enable the Physical Interface and Configure Ethernet Settings, on
page 634.
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.

Firepower Management Center Configuration Guide, Version 6.3

642
 Firepower Threat Defense Interfaces and Device Settings
Configure an EtherChannel

Step 6 Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Step 7 (Optional) Add a VLAN subinterface. See Add a Subinterface, on page 646.
Step 8 Configure the routed or transparent mode interface parameters. See Configure Routed Mode Interfaces, on
page 651 or Configure Bridge Group Interfaces, on page 653.

Configure an EtherChannel
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

This section describes how to create an EtherChannel port-channel interface, assign interfaces to the
EtherChannel, and customize the EtherChannel.
• You can configure up to 48 EtherChannels.
• Each channel group can have up to 16 active interfaces. For switches that support only 8 active interfaces,
you can assign up to 16 interfaces to a channel group: while only 8 interfaces can be active, the remaining
interfaces can act as standby links in case of interface failure.
• All interfaces in the channel group must be the same type, speed, and duplex. Half duplex is not supported.

Note For the Firepower 4100/9300, you configure EtherChannels in FXOS. See Add an EtherChannel (Port Channel),
on page 613 for more information.

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 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Firepower Management Center Configuration Guide, Version 6.3

643
 Firepower Threat Defense Interfaces and Device Settings
Configure an EtherChannel

Step 2 Enable the member interfaces according to Enable the Physical Interface and Configure Ethernet Settings, on
page 634.
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.
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:
• 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 639.
• LACP Mode—Choose Active, Passive, or On. We recommend using Active mode (the default).
• 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 8. If your switch does not support 16 active interfaces, be sure to set this command
to 8 or fewer.
• Active Mac Address—Set a manual MAC address if desired. The mac_address is in H.H.H format,
where H is a 16-bit hexadecimal digit. For example, the MAC address 00-0C-F1-42-4C-DE is entered
as 000C.F142.4CDE.

Step 7 (Optional) Click the Hardware Configuration tab and set the Duplex and Speed to override these settings
for all member interfaces. This method provides a shortcut to set these parameters because these parameters
must match for all interfaces in the channel group.
Step 8 Click OK.
Step 9 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Step 10 (Optional) Add a VLAN subinterface. See Add a Subinterface, on page 646.
Step 11 Configure the routed or transparent mode interface parameters. See Configure Routed Mode Interfaces, on
page 651 or Configure Bridge Group Interfaces, on page 653.

Firepower Management Center Configuration Guide, Version 6.3

644
 Firepower Threat Defense Interfaces and Device Settings
Configure VLAN Subinterfaces and 802.1Q Trunking

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

High Availability
You cannot use a subinterface for the failover or state link. The exception is that you can use a subinterface
defined on the Firepower 4100/9300 chassis for container instances.

Additional Guidelines
• Preventing untagged packets on the physical interface—If you use subinterfaces, you typically do not
also want the physical interface to pass traffic, because the physical interface passes untagged packets.
This property is also true for the active physical interface in a redundant interface pair and for EtherChannel
links. Because the physical, redundant, or EtherChannel interface must be enabled for the subinterface
to pass traffic, ensure that the physical, redundant, or EtherChannel interface does not pass traffic by not
configuring a name for the interface. If you want to let the physical, redundant, or EtherChannel interface
pass untagged packets, you can configure the name as usual.
• You cannot configure subinterfaces on the Diagnostic interface.
• All subinterfaces on the same parent interface must be either bridge group members or routed interfaces;
you cannot mix and match.
• The FTD does not support the Dynamic Trunking Protocol (DTP), so you must configure the connected
switch port to trunk unconditionally.
• You might want to assign unique MAC addresses to subinterfaces defined on the FTD, because they use
the same burned-in MAC address of the parent interface. For example, your service provider might
perform access control based on the MAC address. Also, because IPv6 link-local addresses are generated
based on the MAC address, assigning unique MAC addresses to subinterfaces allows for unique IPv6
link-local addresses, which can avoid traffic disruption in certain instances on the FTD.

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

ASA 5508-X 50

ASA 5512-X 100

Firepower Management Center Configuration Guide, Version 6.3

645
 Firepower Threat Defense Interfaces and Device Settings
Add a Subinterface

Model Maximum VLAN Subinterfaces

ASA 5515-X 100

ASA 5516-X 100

ASA 5525-X 200

ASA 5545-X 300

ASA 5555-X 500

Firepower 2100 1024

Firepower 4100 1024

Firepower 9300 1024

Firepower Threat Defense Virtual 50

ISA 3000 25

Add a Subinterface
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 614. 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.

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 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.
Step 2 Enable the parent interface according to Enable the Physical Interface and Configure Ethernet Settings, on
page 634.
Step 3 Click Add Interfaces > Sub Interface.
Step 4 On the General tab, set the following parameters:

Firepower Management Center Configuration Guide, Version 6.3

646
 Firepower Threat Defense Interfaces and Device Settings
Configure Routed and Transparent Mode Interfaces

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.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Step 7 Configure the routed or transparent mode interface parameters. See Configure Routed Mode Interfaces, on
page 651 or Configure Bridge Group Interfaces, on page 653.

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

The Firepower Threat Defense device supports two types of interfaces: routed and bridged.
Each Layer 3 routed interface requires an IP address on a unique subnet.
Bridged interfaces belong to a bridge group, and all interfaces are on the same network. The bridge group is
represented by a Bridge Virtual Interface (BVI) that has an IP address on the bridge network. Routed mode
supports both routed and bridged interfaces, and you can route between routed interfaces and BVIs. Transparent
firewall mode only supports bridge group and BVI interfaces.

Routed Mode Deployment

We recommend that you do not configure an IP address for the Diagnostic interface if you do not have an
inside router. The benefit to leaving the IP address off of the Diagnostic interface is that you can place the
Management interface on the same network as any other data interfaces. If you configure the Diagnostic
interface, its IP address is typically on the same network as the Management IP address, and it counts as a
regular interface that cannot be on the same network as any other data interfaces. Because the Management
interface requires Internet access for updates, putting Management on the same network as an inside interface
means you can deploy the FTD device with only a switch on the inside and point to the inside interface as its
gateway. See the following deployment that uses an inside switch:

Firepower Management Center Configuration Guide, Version 6.3

647
 Firepower Threat Defense Interfaces and Device Settings
Routed Mode Deployment

To cable the above scenario on the ASA 5508-X, or ASA 5516-X, see the following:

If you configure the Diagnostic IP address, then you need an inside router:

Firepower Management Center Configuration Guide, Version 6.3

648
 Firepower Threat Defense Interfaces and Device Settings
Transparent Mode Deployment

Transparent Mode Deployment

Like the routed mode deployment, you can choose to deploy the device with an inside switch, in which case
you need to keep the Diagnostic interface without an IP address:

Or you can deploy with an inside router, in which case you can use the Diagnostic interface with an IP address
for additional management access:

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.

Guidelines and Requirements 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.

Firepower Management Center Configuration Guide, Version 6.3

649
 Firepower Threat Defense Interfaces and Device Settings
Guidelines and Requirements for Routed and Transparent Mode Interfaces

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 Support
• For the Firepower 2100 series, bridge groups are not supported in routed mode.
• For the Firepower Threat Defense Virtual, 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.
• For IPv4, an IP address for the BVI is required for each bridge group for both management traffic and
for traffic to pass through the Firepower Threat Defense device. IPv6 addresses are supported, but not
required for the BVI.
• 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 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, EtherChannel interfaces are not supported as 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

Firepower Management Center Configuration Guide, Version 6.3

650
 Firepower Threat Defense Interfaces and Device Settings
Configure Routed Mode Interfaces

will drop BFD echo packets because they have the same source and destination IP address and appear
to be part of a LAND attack.

Configure Routed Mode Interfaces

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

This procedure describes how to set the name, security zone, and IPv4 address.

Before you begin

• Firepower 4100/9300—Configure a Physical Interface, on page 612
• Configure any special interfaces.
Firepower 4100/9300:
• Add an EtherChannel (Port Channel), on page 613
• Add a VLAN Subinterface for Container Instances, on page 614 in FXOS
• Add a Subinterface, on page 646 in FMC

All other models:

• Configure a Redundant Interface, on page 642
• Configure an EtherChannel, on page 643
• Add a Subinterface, on page 646

Procedure

Step 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 In the Name field, enter a name up to 48 characters in length.
Step 4 Enable the interface by checking the Enabled check box.
Step 5 (Optional) Set this interface to Management Only to limit traffic to management traffic; through-the-box
traffic is not allowed.
Step 6 (Optional) Add a description in the Description field.
The description can be up to 200 characters on a single line, without carriage returns.

Step 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.

Firepower Management Center Configuration Guide, Version 6.3

651
 Firepower Threat Defense Interfaces and Device Settings
Configure Routed Mode Interfaces

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 668 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.
• Use Static IP—Enter the IP address and subnet mask. For High Availabilty, you can only use a static
IP address. Set the standby IP address on the Devices > Device Management > High Availability tab
in the Monitored Interfaces area. If you do not set the standby IP address, the active unit cannot monitor
the standby interface using network tests; it can only track the link state.
• Use DHCP—Configure the following optional parameters:
• Obtain default route using DHCP—Obtains the default route from the DHCP server.
• DHCP route metric—Assigns an administrative distance to the learned route, between 1 and 255.
The default administrative distance for the learned routes is 1.

• Use PPPoE—If the interface is connected to a DSL, cable modem, or other connection to your ISP, and
your ISP uses PPPoE to provide your IP address, configure the following parameters:
• VPDN Group Name—Specify a group name of your choice to represent this connection.
• PPPoE User Name—Specify the username provided by your ISP.
• PPPoE Password/Confirm Password—Specify and confirm the password provided by your ISP.
• PPP Authentication—Choose PAP, CHAP, or MSCHAP.
PAP passes a cleartext username and password during authentication and is not secure. With CHAP,
the client returns the encrypted [challenge plus password], with a cleartext username in response to
the server challenge. CHAP is more secure than PAP, but it does not encrypt data. MSCHAP is
similar to CHAP but is more secure because the server stores and compares only encrypted passwords
rather than cleartext passwords as in CHAP. MSCHAP also generates a key for data encryption by
MPPE.
• PPPoE route metric—Assign an administrative distance to the learned route. Valid values are from
1 to 255. By default, the administrative distance for the learned routes is 1.
• Enable Route Settings—To manually configure the PPPoE IP address, check this box and then
enter the IP Address.
• 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 657 to configure IPv6 addressing on the IPv6 tab.
Step 12 (Optional) See Configure the MAC Address, on page 669 to manually configure the MAC address on the
Advanced tab.
Step 13 (Optional) Set the duplex and speed by clicking the Hardware Configuration tab.
• Duplex—Choose Full, Half, or Auto. Auto is the default when the interface supports it. For example,
you cannot select Auto for the SFP interfaces on a Firepower 2100 series device.
• Speed—Choose 10, 100, 1000, or Auto. Auto is the default. The type of interface limits the options you
can select. For example, on Firepower 2100 series devices, you can select 10, 100, or 1000 (1Gbps) for

Firepower Management Center Configuration Guide, Version 6.3

652
 Firepower Threat Defense Interfaces and Device Settings
Configure Bridge Group Interfaces

GigabitEthernet ports, and 1000 or 10000 (10 Gpbs) for SFP ports. Note that the SFP interfaces on
Firepower 2100 series devices do not support Auto.

Step 14 Click OK.

Step 15 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

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 579.
To configure bridge groups and associated interfaces, perform these steps.

Configure General Bridge Group Member Interface Parameters

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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,
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—Configure a Physical Interface, on page 612
• Configure any special interfaces.
Firepower 4100/9300:
• Add an EtherChannel (Port Channel), on page 613
• Add a VLAN Subinterface for Container Instances, on page 614 in FXOS
• Add a Subinterface, on page 646 in FMC

All other models:

• Configure a Redundant Interface, on page 642
• Configure an EtherChannel, on page 643
• Add a Subinterface, on page 646

Firepower Management Center Configuration Guide, Version 6.3

653
 Firepower Threat Defense Interfaces and Device Settings
Configure the Bridge Virtual Interface (BVI)

Procedure

Step 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 In the Name field, enter a name up to 48 characters in length.
Step 4 Enable the interface by checking the Enabled check box.
Step 5 (Optional) Set this interface to Management Only to limit traffic to management traffic; through-the-box
traffic is not allowed.
Step 6 (Optional) Add a description in the Description field.
The description can be up to 200 characters on a single line, without carriage returns.

Step 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. After
you assign this interface to a bridge group, the mode will show as Switched.

Step 8 From the Security Zone drop-down list, choose a security zone or add a new one by clicking New.
The bridge group member interface is a Switched-type interface, and can only belong to Switched-type zones.
Do not configure any IP address settings for this interface. You will set the IP address for the Bridge Virtual
Interface (BVI) only. Note that the BVI does not belong to a zone, and you cannot apply access control policies
to the BVI.

Step 9 See Configure the MTU, on page 668 for information about the MTU.
Step 10 (Optional) Set the duplex and speed by clicking the Hardware Configuration tab.
• Duplex—Choose Full, Half, or Auto. Auto is the default when the interface supports it. For example,
you cannot select Auto for the SFP interfaces on a Firepower 2100 series device.
• Speed—Choose 10, 100, 1000, or Auto. Auto is the default. The type of interface limits the options you
can select. For example, on Firepower 2100 series devices, you can select 10, 100, or 1000 (1Gbps) for
GigabitEthernet ports, and 1000 or 10000 (10 Gpbs) for SFP ports. Note that the SFP interfaces on
Firepower 2100 series devices do not support Auto.

Step 11 (Optional) See Configure IPv6 Addressing, on page 657 to configure IPv6 addressing on the IPv6 tab.
Step 12 (Optional) See Configure the MAC Address, on page 669 to manually configure the MAC address on the
Advanced tab.
Step 13 Click OK.
Step 14 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

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

Firepower Management Center Configuration Guide, Version 6.3

654
Firepower Threat Defense Interfaces and Device Settings
Configure the Bridge Virtual Interface (BVI)

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 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.
Step 2 Choose Add Interfaces > Bridge Group Interface.
Step 3 (Routed Mode) In the Name field, enter a name up to 48 characters in length.
You must name the BVI if you want to route traffic outside the bridge group members, for example, to the
outside interface or to members of other bridge groups. The name is not case-sensitive.

Step 4 In the Bridge Group ID field, enter the bridge group ID between 1 and 250.
Step 5 In the Description field, enter a description for this bridge group.
Step 6 On the Interfaces tab, click an interface and then click Add to move it to the Selected Interfaces area. Repeat
for all interfaces that you want to make members of the bridge group.
Step 7 (Transparent Mode) Click the IPv4 tab. In the IP Address field, enter the IPv4 address and subnet mask.
Do not assign a host address (/32 or 255.255.255.255) to the BVI. Also, do not use other subnets that contain
fewer than 3 host addresses (one each for the upstream router, downstream router, and transparent firewall)
such as a /30 subnet (255.255.255.252). The FTD device drops all ARP packets to or from the first and last
addresses in a subnet. For example, if you use a /30 subnet and assign a reserved address from that subnet to
the upstream router, then the FTD device drops the ARP request from the downstream router to the upstream
router.
For High Availabilty, set the standby IP address on the Devices > Device Management > High Availability
tab in the Monitored Interfaces area. If you do not set the standby IP address, the active unit cannot monitor
the standby interface using network tests; it can only track the link state.

Step 8 (Routed Mode) Click the IPv4 tab. To set the IP address, use one of the following options from the IP Type
drop-down list.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

655
 Firepower Threat Defense Interfaces and Device Settings
Configure a Diagnostic (Management) Interface for Transparent Mode

• 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 657 to configure IPv6 addressing.
Step 10 (Optional) See Add a Static ARP Entry, on page 670 and Add a Static MAC Address and Disable MAC
Learning for a Bridge Group, on page 671 (for transparent mode only) to configure the ARP and MAC settings.
Step 11 Click OK.
Step 12 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Configure a Diagnostic (Management) Interface for Transparent Mode

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

In transparent firewall mode, all interfaces must belong to a bridge group. The only exception is the Diagnostic
slot/port interface. For the Firepower 4100/9300 chassis, the diagnostic interface ID depends on the mgmt-type
interface that you assigned to the FTD logical device. You cannot use any other interface types as diagnostic
interfaces. You can configure one diagnostic interface.

Before you begin

Do not assign this interface to a bridge group; a non-configurable bridge group (ID 301) is automatically
added to your configuration. This bridge group is not included in the bridge group limit.

Procedure

Step 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) for the Diagnostic interface.

Step 3 In the Name field, enter a name up to 48 characters in length.
Step 4 Click the IPv4 tab. To set the IP address, use one of the following options from the IP Type drop-down list.
• Use Static IP—Enter the IP address and subnet mask.
• Use DHCP—Configure the following optional parameters:
• Obtain default route using DHCP—Obtains the default route from the DHCP server.

Firepower Management Center Configuration Guide, Version 6.3

656
 Firepower Threat Defense Interfaces and Device Settings
Configure IPv6 Addressing

• 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—Configure the following parameters:

• VPDN Group Name—Specify a group name.
• PPPoE User Name—Specify the username provided by your ISP.
• PPPoE Password/Confirm Password—Specify and confirm the password provided by your ISP.
• PPP Authentication—Choose PAP, CHAP, or MSCHAP.
PAP passes a cleartext username and password during authentication and is not secure. With CHAP,
the client returns the encrypted [challenge plus password], with a cleartext username in response to
the server challenge. CHAP is more secure than PAP, but it does not encrypt data. MSCHAP is
similar to CHAP but is more secure because the server stores and compares only encrypted passwords
rather than cleartext passwords as in CHAP. MSCHAP also generates a key for data encryption by
MPPE.
• PPPoE route metric—Assign an administrative distance to the learned route. Valid values are from
1 to 255. By default, the administrative distance for the learned routes is 1.
• Enable Route Settings—To manually configure the PPPoE IP address, check this box and then
enter the IP Address.
• 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 5 (Optional) See Configure IPv6 Addressing, on page 657 to configure IPv6 addressing.
Step 6 (Optional) On the Advanced tab, configure optional settings.
• See Configure the MAC Address, on page 669.
• See Add a Static ARP Entry, on page 670.
• See Set Security Configuration Parameters, on page 672.

Step 7 Click OK.

Step 8 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Configure IPv6 Addressing

This section describes how to configure IPv6 addressing in routed and transparent mode.

About IPv6
This section includes information about IPv6.

Firepower Management Center Configuration Guide, Version 6.3

657
 Firepower Threat Defense Interfaces and Device Settings
IPv6 Addressing

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.

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

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

To configure a global IPv6 address for any routed mode interface and for the transparent or routed mode BVI,
perform the following steps.

Firepower Management Center Configuration Guide, Version 6.3

658
Firepower Threat Defense Interfaces and Device Settings
Configure a Global IPv6 Address

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 669.

Procedure

Step 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 Click the IPv6 tab.
For routed mode, the Basic tab is selected by default. For transparent mode, the Address tab is selected by
default.

Step 4 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:
1. Click the Address tab, and click Add Address.
The Add Address dialog box appears.
2. 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 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 5 For Routed interfaces, you can optionally set the following values on the Basic tab:

Firepower Management Center Configuration Guide, Version 6.3

659
 Firepower Threat Defense Interfaces and Device Settings
Configure a Global IPv6 Address

• To automatically configure the link-local address when you do not configure the global address, check
the Enable IPv6 check box.
If you do not want to configure a global address, and only need to configure a link-local address, you
have the option of generating the link-local addresses based on the interface MAC addresses (Modified
EUI-64 format. Because MAC addresses use 48 bits, additional bits must be inserted to fill the 64 bits
required for the interface ID.)
• 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 6 For Routed interfaces, see Configure IPv6 Neighbor Discovery, on page 661 to configure settings on the
Prefixes and Settings tabs. For BVI interfaces, see the following parameters on the Settings tab:
• 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 7 Click OK.

Step 8 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

660
 Firepower Threat Defense Interfaces and Device Settings
Configure IPv6 Neighbor Discovery

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Configure IPv6 Neighbor Discovery

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Procedure

Step 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 Click the IPv6 tab, and then the Prefixes tab.
Step 4 (Optional) To configure which IPv6 prefixes are included in IPv6 router advertisements, perform the following
steps:
a) Click Add Prefix.
b) In the Address field, enter the IPv6 address with the prefix length or check the Default check box to use
the default prefix.
c) (Optional) Uncheck the Advertisement check box to indicate that the IPv6 prefix is not advertised.
d) Check the Off Link check box to indicate that the specified prefix is assigned to the link. Nodes sending
traffic to addresses that contain the specified prefix consider the destination to be locally reachable on the
link. This prefix should not be used for on-link determination.
e) To use the specified prefix for autoconfiguration, check the Autoconfiguration check box.
f) For the Prefix Lifetime, click Duration or Expiration Date.
• Duration—Enter a Preferred Lifetime for the prefix in seconds. This setting is the amount of time
that the specified IPv6 prefix is advertised as being valid. The maximum value represents infinity.
Valid values are from 0 to 4294967295. The default is 2592000 (30 days). Enter a Valid Lifetime
for the prefix in seconds. This setting is the amount of time that the specified IPv6 prefix is advertised

Firepower Management Center Configuration Guide, Version 6.3

661
 Firepower Threat Defense Interfaces and Device Settings
Configure IPv6 Neighbor Discovery

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 the Settings tab.
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.

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.

Firepower Management Center Configuration Guide, Version 6.3

662
 Firepower Threat Defense Interfaces and Device Settings
Configure Advanced Interface Settings

Router advertisement messages (ICMPv6 Type 134) are automatically sent in response to router solicitation
messages (ICMPv6 Type 133). Router solicitation messages are sent by hosts at system startup so that the
host can immediately autoconfigure without needing to wait for the next scheduled router advertisement
message.
You may want to disable these messages on any interface for which you do not want the Firepower Threat
Defense device to supply the IPv6 prefix (for example, the outside interface).
• RA Lifetime—Configure the router lifetime value in IPv6 router advertisements, between 0 and 9000
seconds.
The default is 1800 seconds.
• RA Interval—Configure the interval between IPv6 router advertisement transmissions, between 3 and
1800 seconds.
The default is 200 seconds.

Step 10 Click OK.

Step 11 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

663
 Firepower Threat Defense Interfaces and Device Settings
Default MAC Addresses

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.

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.
• 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 ASA.
• Subinterfaces (Firepower 4100/9300-defined)—All subinterfaces for use with container instances use
unique autogenerated MAC addresses. 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.

For container instances:

• MAC addresses for all interfaces are taken from a MAC address pool. See Automatic MAC Addresses
for Container Instance Interfaces, on page 606.

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.

Firepower Management Center Configuration Guide, Version 6.3

664
 Firepower Threat Defense Interfaces and Device Settings
Path MTU Discovery

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 665.
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 Firepower Threat
Defense device 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 FTD on the Firepower 4100/9300 chassis.

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 953; 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.

Firepower Management Center Configuration Guide, Version 6.3

665
 Firepower Threat Defense Interfaces and Device Settings
Default TCP MSS

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 953. 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.

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.

Firepower Management Center Configuration Guide, Version 6.3

666
 Firepower Threat Defense Interfaces and Device Settings
MAC Address Table for Bridge Groups

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 for Bridge Groups

The Firepower Threat Defense device 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 Firepower Threat Defense device
adds the MAC address to its table. The table associates the MAC address with the source interface so that the
Firepower Threat Defense device knows to send any packets addressed to the device out the correct interface.
Because the Firepower Threat Defense device is a firewall, if the destination MAC address of a packet is not
in the table, the Firepower Threat Defense device 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 Firepower Threat Defense device 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 Firepower Threat Defense device 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.
• 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.

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.

Firepower Management Center Configuration Guide, Version 6.3

667
 Firepower Threat Defense Interfaces and Device Settings
Configure the MTU

Configure the MTU

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

Customize the MTU on the interface, for example, to allow jumbo frames.

Caution Changing the highest MTU value on the device for a non-management/diagnostic interface restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management/diagnostic interfaces, not just the interface you modified. Whether this
interruption drops traffic or passes it without further inspection depends on the model of the managed device
and the interface type. See Snort® Restart Traffic Behavior, on page 312 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 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 On the General tab, set the MTU between 64 and 9198 bytes; the maximum is 9000 for the Firepower Threat
Defense Virtual and 9184 for the FTD on the Firepower 4100/9300 chassis.
The default is 1500 bytes.

Step 4 Click OK.

Step 5 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Step 6 For ASA models, if you set the MTU above 1500 bytes, reload the system to enable jumbo frames.

Firepower Management Center Configuration Guide, Version 6.3

668
 Firepower Threat Defense Interfaces and Device Settings
Configure the MAC Address

Configure the MAC Address

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 Click the Advanced tab.
The Information tab is selected.
Step 4 In the Active MAC Address field, enter a MAC address in H.H.H format, where H is a 16-bit hexadecimal
digit.
For example, the MAC address 00-0C-F1-42-4C-DE would be entered as 000C.F142.4CDE. The MAC address
must not have the multicast bit set, that is, the second hexadecimal digit from the left cannot be an odd number.

Step 5 In the Standby MAC Address field, enter a MAC address for use with High Availability.
If the active unit fails over and the standby unit becomes active, the new active unit starts using the active
MAC addresses to minimize network disruption, while the old active unit uses the standby address.

Step 6 Click OK.

Step 7 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Firepower Management Center Configuration Guide, Version 6.3

669
 Firepower Threat Defense Interfaces and Device Settings
Add a Static ARP Entry

Add a Static ARP Entry

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

By default, all ARP packets are allowed between bridge group members. You can control the flow of ARP
packets by enabling ARP inspection (see Configure ARP Inspection, on page 1091). 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 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 Click the Advanced tab, and then click the ARP tab (called ARP and MAC for transparent mode).
Step 4 Click Add ARP Config.
The Add ARP Config dialog box appears.
Step 5 In the IP Address field, enter the IP address of the host.
Step 6 In the MAC Address field, enter the MAC address of the host; for example, 00e0.1e4e.3d8b.
Step 7 To perform proxy ARP for this address, check the Enable Alias check box.
If the FTD device receives an ARP request for the specified IP address, then it responds with the specified
MAC address.

Step 8 Click OK, and then click OK again to exit the Advanced settings.
Step 9 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

670
 Firepower Threat Defense Interfaces and Device Settings
Add a Static MAC Address and Disable MAC Learning for a Bridge Group

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Add a Static MAC Address and Disable MAC Learning for a Bridge Group
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

Normally, MAC addresses are added to the MAC address table dynamically as traffic from a particular MAC
address enters an interface. You can disable MAC address learning; however, unless you statically add MAC
addresses to the table, no traffic can pass through the FTD device. You can also add static MAC addresses to
the MAC address table. One benefit to adding static entries is to guard against MAC spoofing. If a client with
the same MAC address as a static entry attempts to send traffic to an interface that does not match the static
entry, then the FTD device drops the traffic and generates a system message. When you add a static ARP
entry (see Add a Static ARP Entry, on page 670), a static MAC address entry is automatically added to the
MAC address table.

Before you begin

This screen is only available for named interfaces.

Procedure

Step 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 Click the Advanced tab, and then click the ARP and MAC tab.
Step 4 (Optional) Disable MAC learning by unchecking the Enable MAC Learning check box.
Step 5 To add a static MAC address, click Add MAC Config.
The Add MAC Config dialog box appears.
Step 6 In the MAC Address field, enter the MAC address of the host; for example, 00e0.1e4e.3d8b. Click OK.
Step 7 Click OK to exit the Advanced settings.
Step 8 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Firepower Management Center Configuration Guide, Version 6.3

671
 Firepower Threat Defense Interfaces and Device Settings
Set Security Configuration Parameters

Set Security Configuration Parameters

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

This section describes how to prevent IP spoofing, allow full fragment reassembly, and override the default
fragment setting set for at the device level in Platform Settings .
Anti-Spoofing
This section lets you enable Unicast Reverse Path Forwarding on an interface. Unicast RPF guards against
IP spoofing (a packet uses an incorrect source IP address to obscure its true source) by ensuring that all packets
have a source IP address that matches the correct source interface according to the routing table.
Normally, the FTD device only looks at the destination address when determining where to forward the packet.
Unicast RPF instructs the device to also look at the source address; this is why it is called Reverse Path
Forwarding. For any traffic that you want to allow through the FTD device, the device routing table must
include a route back to the source address. See RFC 2267 for more information.
For outside traffic, for example, the FTD device can use the default route to satisfy the Unicast RPF protection.
If traffic enters from an outside interface, and the source address is not known to the routing table, the device
uses the default route to correctly identify the outside interface as the source interface.
If traffic enters the outside interface from an address that is known to the routing table, but is associated with
the inside interface, then the FTD device drops the packet. Similarly, if traffic enters the inside interface from
an unknown source address, the device drops the packet because the matching route (the default route) indicates
the outside interface.
Unicast RPF is implemented as follows:
• ICMP packets have no session, so each packet is checked.
• UDP and TCP have sessions, so the initial packet requires a reverse route lookup. Subsequent packets
arriving during the session are checked using an existing state maintained as part of the session. Non-initial
packets are checked to ensure they arrived on the same interface used by the initial packet.

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.

Firepower Management Center Configuration Guide, Version 6.3

672
Firepower Threat Defense Interfaces and Device Settings
Set Security Configuration Parameters

• 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

This screen is only available for named interfaces.

Procedure

Step 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 Click the Advanced tab, and then click the Security Configuration tab.
Step 4 To enable Unicast Reverse Path Forwarding, check the Anti-Spoofing check box.
Step 5 To enable full fragment reassembly, check the Full Fragment Reassembly check box.
Step 6 To change the number of fragments allowed per packet, check the Override Default Fragment Setting check
box, and set the following values:
• Size—Set the maximum number of packets that can be in the IP reassembly database waiting for
reassembly. The default is 200. Set this value to 1 to disable fragments.
• Chain—Set the maximum number of packets into which a full IP packet can be fragmented. The default
is 24 packets.
• Timeout—Set the maximum number of seconds to wait for an entire fragmented packet to arrive. The
timer starts after the first fragment of a packet arrives. If all fragments of the packet do not arrive by the
number of seconds specified, all fragments of the packet that were already received will be discarded.
The default is 5 seconds.

Step 7 Click OK.

Step 8 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Firepower Management Center Configuration Guide, Version 6.3

673
 Firepower Threat Defense Interfaces and Device Settings
History for Regular Firewall Interfaces for Firepower Threat Defense

History for Regular Firewall Interfaces for Firepower Threat

Defense
Feature Version Details

VLAN subinterfaces for use with container 6.3.0 To provide flexible physical interface use,
instances you can create VLAN subinterfaces in
FXOS and also share interfaces between
multiple instances.
New/Modified Firepower Management
Center screens:
Devices > Device Management > Edit
icon > Interfaces tab
New/Modified Firepower Chassis Manager
screens:
Interfaces > All Interfaces > Add New
drop-down menu > Subinterface
New/Modified FXOS commands: create
subinterface, set vlan, show
interface,show subinterface
Supported platforms: Firepower 4100/9300

Data-sharing interfaces for container 6.3.0 To provide flexible physical interface use,
instances you can share interfaces between multiple
instances.
New/Modified Firepower Chassis
Managerscreens:
Interfaces > All Interfaces > Type
New/Modified FXOS commands: set
port-type data-sharing, show interface
Supported platforms: Firepower 4100/9300

Firepower Management Center Configuration Guide, Version 6.3

674
 Firepower Threat Defense Interfaces and Device Settings
History for Regular Firewall Interfaces for Firepower Threat Defense

Feature Version Details

Integrated Routing and Bridging 6.2.0 Integrated Routing and Bridging provides
the ability to route between a bridge group
and a 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

Firepower Management Center Configuration Guide, Version 6.3

675
 Firepower Threat Defense Interfaces and Device Settings
History for Regular Firewall Interfaces for Firepower Threat Defense

Firepower Management Center Configuration Guide, Version 6.3

676
 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 Hardware Bypass for Inline Sets, on page 677
• Prerequisites for Inline Sets, on page 678
• Guidelines for Inline Sets and Passive Interfaces, on page 679
• Configure a Passive Interface, on page 679
• Configure an Inline Set, on page 681
• History for Inline Sets and Passive Interfaces for Firepower Threat Defense, on page 684

About Hardware Bypass for Inline Sets

For certain interface modules on the Firepower 9300, 4100, and 2100 series (see Prerequisites for Inline Sets,
on page 678), 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
• Security Module reboot
• Firepower chassis crash
• Firepower chassis reboot or upgrade
• Manual trigger
• Firepower chassis power loss
• Security Module power loss

Firepower Management Center Configuration Guide, Version 6.3

677
 Firepower Threat Defense Interfaces and Device Settings
Hardware Bypass Switchover

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.

Prerequisites for Inline Sets

Hardware Bypass Support
The FTD supports Hardware Bypass for interface pairs on specific network modules on the following models:
• Firepower 9300
• Firepower 4100 series
• Firepower 2100 series

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

Firepower Management Center Configuration Guide, Version 6.3

678
 Firepower Threat Defense Interfaces and Device Settings
Guidelines for Inline Sets and Passive Interfaces

•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.
• Bidirectional Forwarding Detection (BFD) echo packets are not allowed through the FTD when using
inline sets. If there are two neighbors on either side of the FTD running BFD, then the FTD will drop
BFD echo packets because they have the same source and destination IP address and appear to be part
of a LAND attack.

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.

Configure a Passive Interface

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

Firepower Management Center Configuration Guide, Version 6.3

679
 Firepower Threat Defense Interfaces and Device Settings
Configure a Passive Interface

This section describes how to:

• Enable the interface. By default, interfaces are disabled.
• 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 664.
• 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 612 for more information.

Procedure

Step 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 In the Mode drop-down list, choose Passive or Erspan.
Step 4 Enable the interface by checking the Enabled check box.
Step 5 In the Name field, enter a name up to 48 characters in length.
Step 6 From the Security Zone drop-down list, choose a security zone or add a new one by clicking New.
Step 7 (Optional) Add a description in the Description field.
The description can be up to 200 characters on a single line, without carriage returns.

Step 8 (Optional) On the General tab, 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 the IPv4 tab.
Step 11 (Optional) Set the duplex and speed by clicking the Hardware Configuration tab.
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.

Firepower Management Center Configuration Guide, Version 6.3

680
 Firepower Threat Defense Interfaces and Device Settings
Configure an Inline Set

Step 12 Click OK.

Step 13 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Configure an Inline Set

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 612 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

Step 1 Select Devices > Device Management and click the edit icon ( ) for your FTD device. The Interfaces tab
is selected by default.

Step 2 Click the edit icon ( ) for the interface you want to edit.
Step 3 In the Mode drop-down list, choose None.
After you add this interface to an inline set, this field will show Inline for the mode.

Step 4 Enable the interface by checking the Enabled check box.

Step 5 In the Name field, enter a name up to 48 characters in length.
Step 6 In the Security Zone drop-down list, choose a security zone or add a new one by clicking New.
Step 7 (Optional) Add a description in the Description field.
The description can be up to 200 characters on a single line, without carriage returns.

Step 8 (Optional) Set the duplex and speed by clicking the Hardware Configuration tab.

Firepower Management Center Configuration Guide, Version 6.3

681
 Firepower Threat Defense Interfaces and Device Settings
Configure an Inline Set

The exact speed and duplex options depend on your hardware.

• Duplex—Choose Full, Half, or Auto. Auto is the default.
• Speed—Choose 10, 100, 1000, or Auto. Auto is the default.

Step 9 Click OK.

Do not set any other settings for this interface.

Step 10 Click the edit icon ( ) for the second interface you want to add to the inline set.
Step 11 Configure the settings as for the first interface.
Step 12 Click the Inline Sets tab.
Step 13 Click Add Inline Set.
The Add Inline Set dialog box appears with the General tab selected.
Step 14 In the Name field, enter a name for the set.
Step 15 (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 16 (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. The Inline Sets tab shows
Yes for any interface pairs that are in Bypass-Force mode.

Step 17 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 18 (Optional) Click the Advanced tab 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.

Firepower Management Center Configuration Guide, Version 6.3

682
Firepower Threat Defense Interfaces and Device Settings
Configure an Inline Set

• 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
• 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 313.
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 19 Click the Interfaces tab.

Step 20 Click the edit icon ( ) for one of the member interfaces.
Step 21 From the Security Zone drop-down list, choose a security zone or add a new one by clicking New.
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 22 Click OK.

Step 23 Set the security zone for the second interface.
Step 24 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Firepower Management Center Configuration Guide, Version 6.3

683
 Firepower Threat Defense Interfaces and Device Settings
History for Inline Sets and Passive Interfaces for Firepower Threat Defense

History for Inline Sets and Passive Interfaces for Firepower

Threat Defense
Feature Version Details

Hardware bypass support on the Firepower 6.3.0 The Firepower 2100 now supports hardware
2100 for supported network modules bypass functionality when using the
hardware bypass network modules.
New/Modified screens:
Devices > Device Management >
Interfaces > Edit Physical Interface
Supported platforms: Firepower 2100

Support for EtherChannels in FTD inline 6.2.0 You can now use EtherChannels in a FTD
sets inline set.
Supported platforms: Firepower 4100/9300

Hardware bypass support on the Firepower 6.1.0 Hardware Bypass ensures that traffic
4100/9300 for supported network modules continues to flow between an inline
interface pair during a power outage. This
feature can be used to maintain network
connectivity in the case of software or
hardware failures.
New/Modified screens:
Devices > Device Management >
Interfaces > Edit Physical Interface
Supported platforms: Firepower 4100/9300

Inline set link state propagation support for 6.1.0 When you configure an inline set in the
the FTD FTD application and enable link state
propagation, the FTD sends inline set
membership to the FXOS chassis. Link
state propagation means that the chassis
automatically brings down the second
interface in the inline interface pair when
one of the interfaces in an inline set goes
down.
New/Modified FXOS commands: show
fault |grep link-down, show interface
detail
Supported platforms: Firepower 4100/9300

Firepower Management Center Configuration Guide, Version 6.3

684
 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 685
• Guidelines for DHCP and DDNS Services, on page 687
• Configure the DHCP Server, on page 688
• Configure the DHCP Relay Agent, on page 690
• Configure DDNS, on page 691

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.
• DHCP option 3 sets the default route.

Firepower Management Center Configuration Guide, Version 6.3

685
 Firepower Threat Defense Interfaces and Device Settings
About the DHCP Relay Agent

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.

About DDNS
DDNS update integrates DNS with DHCP. The two protocols are complementary: DHCP centralizes and
automates IP address allocation; DDNS update automatically records the association between assigned
addresses and hostnames at predefined intervals. DDNS allows frequently changing address-hostname
associations to be updated frequently. Mobile hosts, for example, can then move freely on a network without
user or administrator intervention. DDNS provides the necessary dynamic update and synchronization of the
name-to-address mapping and address-to-name mapping on the DNS server.
The DDNS name and address mapping is held on the DHCP server in two resource records (RRs): the A RR
includes the name-to-IP address mapping, while the PTR RR maps addresses to names. Of the two methods
for performing DDNS updates—the IETF standard defined by RFC 2136 and a generic HTTP method—the
Firepower Threat Defense device supports the IETF method.

Note DDNS is not supported on the BVI or bridge group member interfaces.

DDNS Update Configurations

The two most common DDNS update configurations are the following:
• The DHCP client updates the A RR, while the DHCP server updates the PTR RR.

Firepower Management Center Configuration Guide, Version 6.3

686
 Firepower Threat Defense Interfaces and Device Settings
UDP Packet Size

• The DHCP server updates both the A RR and PTR RR.

In general, the DHCP server maintains DNS PTR RRs on behalf of clients. Clients may be configured to
perform all desired DNS updates. The server may be configured to honor these updates or not. The DHCP
server must know the fully qualified domain name (FQDN) of the client to update the PTR RR. The client
provides an FQDN to the server using a DHCP option called Client FQDN.

UDP Packet Size

DDNS allows DNS requesters to advertise the size of their UDP packets and facilitates the transfer of packets
larger than 512 octets. When a DNS server receives a request over UDP, it identifies the size of the UDP
packet from the OPT RR and scales its response to contain as many resource records as are allowed in the
maximum UDP packet size specified by the requester. The size of the DNS packets can be up to 4096 bytes
for BIND or 1280 bytes for the Windows 2003 DNS Server.

Guidelines for DHCP and DDNS Services

This section includes guidelines and limitations that you should check before configuring 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 a DHCP client or DHCP relay service on an interface on which the server is
enabled. Additionally, DHCP clients must be directly connected to the interface on which the server is
enabled.
• Firepower Threat Defense device does not support QIP DHCP servers for use with the DHCP proxy
service.
• The relay agent cannot be enabled if the DHCP server is also enabled.

Firepower Management Center Configuration Guide, Version 6.3

687
 Firepower Threat Defense Interfaces and Device Settings
Configure the DHCP Server

• 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.
• The relay agent cannot be enabled if the DHCP server feature is also enabled.
• DHCP relay services are not available in transparent firewall mode. You can, however, allow DHCP
traffic through using an access rule. To allow DHCP requests and replies through the Firepower Threat
Defense device, you need to configure two access rules, one that allows DCHP requests from the inside
interface to the outside (UDP destination port 67), and one that allows the replies from the server in the
other direction (UDP destination port 68).
• For IPv4, clients must be directly-connected to the Firepower Threat Defense device and cannot send
requests through another relay agent or a router. For IPv6, the Firepower Threat Defense device supports
packets from another relay server.
• The DHCP clients must be on different interfaces from the DHCP servers to which the Firepower Threat
Defense device relays requests.
• You cannot enable DHCP Relay on an interface in a traffic zone.

Configure the DHCP Server

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

688
Firepower Threat Defense Interfaces and Device Settings
Configure the DHCP Server

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

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 372.
• 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 372.

Step 5 Select the Server tab, click Add, and configure the following options:
• Interface—Choose the interface from the drop-down list. In transparent mode, specify a named bridge
group member interface. In routed mode, specify a named routed interface or a named BVI; do not specify
the bridge group member interface. Note that each bridge group member interface for the BVI must also
be named for the DHCP server to operate.
• Address Pool—The range of IP addresses from lowest to highest that is used by the DHCP server. The
range of IP addresses must be on the same subnet as the selected interface and cannot include the IP
address of the interface itself.
• 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 the Advanced tab, 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 685for 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 372.

Firepower Management Center Configuration Guide, Version 6.3

689
 Firepower Threat Defense Interfaces and Device Settings
Configure the DHCP Relay Agent

• 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

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select DHCP > DHCP Relay.
Step 3 In the Timeout field, enter the amount of time in seconds that the Firepower Threat Defense device waits to
time out the DHCP relay agent. Valid values range from 1 to 3600 seconds. The default value is 60 seconds.
The timeout is for address negotiation through the local DHCP Relay agent.

Step 4 On the DHCP Relay Agent tab, 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.

Firepower Management Center Configuration Guide, Version 6.3

690
 Firepower Threat Defense Interfaces and Device Settings
Configure DDNS

• Enable IPv6 Relay—Enables IPv6 DHCP Relay for this interface.

Step 5 Click OK to save the DHCP relay agent changes.

Step 6 On the DHCP Servers tab, 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 372
• 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.

Configure DDNS
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

Dynamic DNS (DDNS) update integrates DNS with DHCP. DDNS update automatically records the association
between assigned addresses and hostnames, which allows frequently changing address-hostname associations
to be updated efficiently.

Before you begin

• For overview information, see About DDNS, on page 686.
• DDNS is not supported in transparent firewall mode.

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select DHCP > DDNS, and configure the following DDNS options:
• DHCP Client Requests DHCP Server to update Records—Configures the DHCP client to request
that it update the specified records. Available options are Not Selected, No Update, Only PTR, and
Both A and PTR Records. See About DDNS, on page 686 for a description of A and PTR records.
• Enable DHCP Client Broadcast—Enables the DHCP client to use a broadcast address to reach the
DHCP server.
• Dynamic DNS Update—Which records to update for the DDNS updates for the DHCP server. Available
options are Not Selected, Only PTR, and Both A and PTR Records .

Firepower Management Center Configuration Guide, Version 6.3

691
 Firepower Threat Defense Interfaces and Device Settings
Configure DDNS

• Override DHCP Client Requests—Specifies that the DHCP server actions should override any update
actions requested by the DHCP client.

Step 3 On the DHCP Client ID Interface tab, choose the interface from the Available Interfaces list, and then click
Add to move it to the Selected Interfaces list.
Step 4 On the DDNS Interface Settings tab, click Add, and configure the following options:
• Interface—Choose the interface from the drop-down list to add DDNS settings for each configured
interface .
• Method Name—The DDNS update method assigned to the interface.
• Host Name—The host name of the DDNS client.
• DHCP Client requests DHCP server to update requests—Configures the DHCP client to request that
it update the specified records. Available options are Not Selected, No Update, Only PTR, and Both
A and PTR Records. See About DDNS, on page 686 for a description of A and PTR records.
• Dynamic DNS Update—Which records to update for the DDNS updates for the DHCP server. Available
options are Not Selected, Only PTR, and Both A and PTR Records .
• Override DHCP Client Requests—Specifies that the DHCP server actions should override any update
actions requested by the DHCP client.

Step 5 Click OK to save the DDNS interface changes.

Step 6 On the DDNS Update Methods tab, click Add, and configure the following options:
• Method Name—The DDNS update method assigned to the interface.
• Update Interval—The update interval in whole numbers between DNS update attempts configured for
the update method in days (0 to 364), hours (0 to 23), minutes (0 to 59), and seconds (0 to 59). These
units are additive. That is, if you enter 0 days, 0 hours, 5 minutes and 15 seconds, the update method
tries an update every 5 minutes and 15 seconds for as long as the method is active.
• Update Records—Stores server resource record updates that the DNS client updates. Available options
are Not Defined, Both A and PTR Records, and A Records.

Step 7 Click OK to save the DDNS update methods changes.

Step 8 Click Save on the DHCP page to save your changes.

Firepower Management Center Configuration Guide, Version 6.3

692
 CHAPTER 33
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 693
• About QoS Policies, on page 693
• Rate Limiting with QoS Policies, on page 694

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 2444.
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.

Firepower Management Center Configuration Guide, Version 6.3

693
 Firepower Threat Defense Interfaces and Device Settings
Rate Limiting with QoS Policies

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 master 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 1365.

QoS Policies and Multitenancy

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 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.

Rate Limiting with QoS Policies

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Admin/Access

Admin/Network
Admin

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.

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 695.

You can also copy ( ) or edit ( ) an exisiting policy.

Firepower Management Center Configuration Guide, Version 6.3

694
 Firepower Threat Defense Interfaces and Device Settings
Creating a QoS Policy

Step 3 Configure QoS rules; see Configuring QoS Rules, on page 696 and Rule Management: Common Characteristics,
on page 321.
The Rules tab 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 Rule Performance Guidelines,
on page 352.

Step 4 Click Policy Assignments to identify the managed devices targeted by the policy; see Setting Target Devices
for a QoS Policy, on page 696.
If you identified target devices during policy creation, verify your choices.

Step 5 Save the QoS policy.

Step 6 Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Creating a QoS Policy

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Admin

Access Admin
Network Admin

A new QoS policy with no rules performs no rate limiting.

Procedure

Step 1 Choose Devices > QoS.

Step 2 Click New Policy.
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.
You must assign devices before you deploy the policy.

Step 5 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

695
 Firepower Threat Defense Interfaces and Device Settings
Setting Target Devices for a QoS Policy

What to do next
• Configure and deploy the QoS policy; see Rate Limiting with QoS Policies, on page 694.

Setting Target Devices for a QoS Policy

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Admin

Access Admin
Network Admin

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 the delete icon ( ) 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
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring QoS Rules

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Admin/Access

Admin/Network
Admin

When you create or edit a rule, use the upper portion of the rule editor to configure general rule properties.
Use the tabs on the lower portion to configure rule conditions and comments.

Firepower Management Center Configuration Guide, Version 6.3

696
 Firepower Threat Defense Interfaces and Device Settings
QoS Rule Components

Procedure

Step 1 On the Rules tab of the QoS policy editor:

• Add Rule—Click Add Rule.
• Edit Rule—Click the edit icon ( ).

Step 2 Enter a Name.

Step 3 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 prevent matching traffic from being rate limited in that direction.
• Conditions—Click the tab corresponding to the condition 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. 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 697.

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.

Step 6 Click Save to save the policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Rule Performance Guidelines, on page 352

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:

Firepower Management Center Configuration Guide, Version 6.3

697
 Firepower Threat Defense Interfaces and Device Settings
QoS Rule Components

• 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.
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 325 (routed only; required)
• Network Conditions, on page 328
• Port and ICMP Code Conditions, on page 332
• Application Conditions (Application Control), on page 334
• URL Conditions (URL Filtering), on page 342
• User, Realm, and ISE Attribute Conditions (User Control), on page 342
• Custom SGT Conditions, on page 346

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.

Firepower Management Center Configuration Guide, Version 6.3

698
 Firepower Threat Defense Interfaces and Device Settings
History for QOS

History for QOS

Feature Version Details

Rate limit increased 6.2.1 Raised the maximum rate limit from 1,000 Mbps to 100,000 Mbps.
Modified screen: QoS rule editor
Supported platforms: Firepower Threat Defense

Custom SGT and original client 6.2.1 QoS can now rate limit traffic using custom Security Group Tags (SGTs)
network filtering and original client network information (XFF, True-Client-IP, or
custom-defined HTTP headers).
Modified screen: QoS rule editor
Supported platforms: Firepower Threat Defense

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
Supported platforms: Firepower Threat Defense

Firepower Management Center Configuration Guide, Version 6.3

699
 Firepower Threat Defense Interfaces and Device Settings
History for QOS

Firepower Management Center Configuration Guide, Version 6.3

700
PA R T X
Firepower Threat Defense High Availability and
Scalability
• High Availability for Firepower Threat Defense, on page 703
• Clustering for the Firepower Threat Defense, on page 729
 CHAPTER 34
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 703
• Guidelines for High Availability, on page 716
• Add a Firepower Threat Defense High Availability Pair, on page 717
• Configure Optional High Availability Parameters, on page 719
• Manage High Availability, on page 721
• Monitoring High Availability, on page 727

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.

Hardware Requirements
The two units in a High Availability configuration must:
• Be the same model. In addition, for container instances, they must use the same resource profile attributes.

Firepower Management Center Configuration Guide, Version 6.3

703
 Firepower Threat Defense High Availability and Scalability
Software Requirements

If you change the resource profile after you add the High Availability pair to the FMC, update the
inventory for each unit on the Devices > Device Management > Device > System > Inventory dialog
box.
• Have the same number and types of interfaces.
For the Firepower 4100/9300 chassis, all interfaces must be preconfigured in FXOS identically before
you enable High Availability. If you change the interfaces after you enable High Availability, make the
interface changes in FXOS on the standby unit, and then make the same changes on the active unit.

If you are using units with different flash memory sizes in your High Availability configuration, make sure
the unit with the smaller flash memory has enough space to accommodate the software image files and the
configuration files. If it does not, configuration synchronization from the unit with the larger flash memory
to the unit with the smaller flash memory will fail.

Software Requirements
The two units in a High Availability configuration must:
• Be in the same firewall mode (routed or transparent).
• Have the same major (first number), minor (second number), and maintenance (third number) 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 1131.
• Be fully deployed on the Firepower Management Center with no uncommitted changes.
• Not have DHCP or PPPoE configured in any of their interfaces.

License Requirements for FTD Devices in a High Availability Pair

Firepower Threat Defense devices in a high availability configuration must have the same licenses. 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. High availability configurations require two Smart License entitlements; one
for each device in the pair.

Failover and Stateful Failover Links

The failover link and the optional stateful failover link are dedicated connections between the two units. The
same interface on both devices should to be used for failover and stateful failover links.

Firepower Management Center Configuration Guide, Version 6.3

704
 Firepower Threat Defense High Availability and Scalability
Failover Link

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.

For a redundant interface used as the failover link, see the following benefits for added redundancy:
• When a failover unit boots up, it alternates between the member interfaces to detect an active unit.
• If a failover unit stops receiving keepalive messages from its peer on one of the member interfaces, it
switches to the other member interface.

For an EtherChannel used as the failover link, to prevent out-of-order packets, only one interface in the
EtherChannel is used. If that interface fails, then the next interface in the EtherChannel is used. You cannot
alter the EtherChannel configuration while it is in use as a failover link.

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.

Firepower Management Center Configuration Guide, Version 6.3

705
 Firepower Threat Defense High Availability and Scalability
Stateful Failover Link

If you do not use a switch between the units, if the interface fails, the link is brought down on both peers. This
condition may hamper troubleshooting efforts because you cannot easily determine which unit has the failed
interface and caused the link to come down.

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.

Note Cisco recommends that the bandwidth of the stateful failover link should at least match the bandwidth of the
data interfaces.

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. For an
EtherChannel used as the state 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.
Connect a dedicated state 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 appliances 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.
The Firepower Threat Defense device supports Auto-MDI/MDIX on its copper Ethernet ports, so you
can either use a crossover cable or a straight-through cable. If you use a straight-through cable, the
interface automatically detects the cable and swaps one of the transmit/receive pairs to MDIX.

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.
See the following connection scenarios to design a resilient failover network.

Firepower Management Center Configuration Guide, Version 6.3

706
Firepower Threat Defense High Availability and Scalability
Avoiding Interrupted Failover and Data Links

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 14: Connecting with a Single Switch—Not Recommended

Figure 15: 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 16: Connecting with a Different Switch

Figure 17: Connecting with a Cable

Scenario 3—Recommended
If the Firepower Threat Defense data interfaces are connected to more than one set of switches, then a failover
link can be connected to one of the switches, preferably the switch on the secure (inside) side of network, as
shown in the following figure.
Figure 18: Connecting with a Secure Switch

Firepower Management Center Configuration Guide, Version 6.3

707
 Firepower Threat Defense High Availability and Scalability
MAC Addresses and IP Addresses in High Availability

Scenario 4—Recommended
The most reliable failover configurations use a redundant interface on the failover link, as shown in the
following figures.
Figure 19: Connecting with Redundant Interfaces

Figure 20: 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
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.

Firepower Management Center Configuration Guide, Version 6.3

708
 Firepower Threat Defense High Availability and Scalability
Stateful Failover

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.

Supported Features
For Stateful Failover, the following state information is passed to the standby Firepower Threat Defense
device:
• NAT translation table.

Firepower Management Center Configuration Guide, Version 6.3

709
 Firepower Threat Defense High Availability and Scalability
Supported Features

• 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.
• File type detection and blocking—The file type must be identified before failover. If failover occurs
while the original active device is identifying the file, the file type is not synchronized. Even if your
file policy blocks that file type, the new active device downloads the file.

• User identity decisions from the identity policy, including the user-to-IP address mappings gathered
passively through the User Agent and ISE Session Directory, and active authentication through captive

Firepower Management Center Configuration Guide, Version 6.3

710
 Firepower Threat Defense High Availability and Scalability
Unsupported Features

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 Blacklisting—If failover occurs, no events are generated.

• Security Intelligence decisions. However, DNS-based decisions that are in process at the moment of
failover are not completed.
• RA VPN—Remote access VPN end users do not have to reauthenticate or reconnect the VPN session
after a failover. However, applications operating over the VPN connection could lose packets during the
failover process and not recover from the packet loss.

Unsupported Features
For Stateful Failover, the following state information is not passed to the standby Firepower Threat Defense
device:
• Sessions inside plaintext tunnels such as GRE or IP-in-IP. Sessions inside tunnels are not replicated and
the new active node will not be able to reuse existing inspection verdicts to match the correct policy
rules.
• Connections decrypted by the SSL Decryption policy—The decryption states are not synchronized and
current decrypted connections will be blocked with reset. New connections will work correctly.
Connections that are not decrypted (they match a do not decrypt rule) are not affected and are replicated
correctly as any other TCP connection.
• TCP state bypass connections
• Multicast routing.

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

Firepower Management Center Configuration Guide, Version 6.3

711
 Firepower Threat Defense High Availability and Scalability
Failover Health Monitoring

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.

Interface Monitoring
When a unit does not receive hello messages on a monitored interface for 2 polling periods, it runs interface
tests. If all interface tests fail for an interface, but this same interface on the other unit continues to successfully
pass traffic, then the interface is considered to be failed. If the threshold for failed interfaces is met, then a
failover occurs. If the other unit interface also fails all the network tests, then both interfaces go into the
“Unknown” state and do not count towards the failover limit.

Firepower Management Center Configuration Guide, Version 6.3

712
 Firepower Threat Defense High Availability and Scalability
Interface Tests

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:
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. If the status is Up, then the device performs the Network
Activity test.
2. Network Activity test—A received network activity test. The purpose of this test is to generate network
traffic using LANTEST messages to determine which (if either) unit has failed. At the start of the test,
each unit clears its received packet count for its interfaces. As soon as a unit receives any packets during
the test (up to 5 seconds), then the interface is considered operational. If one unit receives traffic and the
other unit does not, then the unit that received no traffic is considered failed. If neither unit received traffic,
then the device starts the ARP test.
3. ARP test—A reading of the unit ARP cache for the 2 most recently acquired entries. One at a time, the
unit sends ARP requests to these machines, attempting to stimulate network traffic. After each request,
the unit counts all received traffic for up to 5 seconds. If traffic is received, the interface is considered
operational. If no traffic is received, an ARP request is sent to the next machine. If at the end of the list
no traffic has been received, the device starts the ping test.
4. Broadcast Ping test—A ping test that consists of sending out a broadcast ping request. The unit then counts
all received packets for up to 5 seconds. If any packets are received at any time during this interval, the
interface is considered operational and testing stops. If no traffic is received, the testing starts over again
with the ARP test.

Interface Status
Monitored interfaces can have the following status:
• Unknown—Initial status. This status can also mean the status cannot be determined.
• Normal—The interface is receiving traffic.
• Normal (Waiting)—The interface is up, but has not yet received a hello packet from the corresponding
interface on the peer unit.
• Normal (Not-Monitored)—The interface is up, but is not monitored by the failover process.
• Testing—Hello messages are not heard on the interface for five poll times.
• Link Down—The interface or VLAN is administratively down.
• Link Down (Waiting)—The interface or VLAN is administratively down and has not yet received a hello
packet from the corresponding interface on the peer unit.
• Link Down (Not-Monitored)—The interface or VLAN is administratively down, but is not monitored
by the failover process.

Firepower Management Center Configuration Guide, Version 6.3

713
 Firepower Threat Defense High Availability and Scalability
Failover Triggers and Detection Timing

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

Table 65: Firepower Threat Defense Failover Times

Failover Triggering Event Minimum Default Maximum

Active unit loses power or stops 800 milliseconds 15 seconds 45 seconds

normal operation.

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.
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).

Firepower Management Center Configuration Guide, Version 6.3

714
 Firepower Threat Defense High Availability and Scalability
Active Unit Determination at Startup

• 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 66: Failover Events

Failure Event Policy Active Group Action Standby Group 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.

Failover link failed at No failover Mark failover link as Become active If the failover link is
startup failed down at startup, both
units become active.

Firepower Management Center Configuration Guide, Version 6.3

715
 Firepower Threat Defense High Availability and Scalability
Guidelines for High Availability

Failure Event Policy Active Group Action Standby Group Action Notes

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.

Guidelines for High Availability

Model Support
• ASA 5506W-X—You must disable interface monitoring for the internal GigabitEthernet 1/9 interface.
These interfaces will not be able to communicate to perform the default interface monitoring checks,
resulting in a switch from active to standby and back again because of expected interface communication
failures.
• Firepower Threat Defense on the 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.

Additional Guidelines
• When the active unit fails over to the standby unit, the connected switch port running Spanning Tree
Protocol (STP) can go into a blocking state for 30 to 50 seconds when it senses the topology change. To
avoid traffic loss while the port is in a blocking state, you can enable the STP PortFast feature on the
switch:
interface interface_id spanning-tree portfast
This workaround applies to switches connected to both routed mode and bridge group interfaces. The
PortFast feature immediately transitions the port into STP forwarding mode upon linkup. The port still
participates in STP. So if the port is to be a part of the loop, the port eventually transitions into STP
blocking mode.
• You cannot enable failover if a local CA server is configured. Remove the CA configuration using the
no crypto ca server command.
• Configuring port security on the switch(es) connected to the Firepower Threat Defense failover pair can
cause communication problems when a failover event occurs. This problem occurs when a secure MAC

Firepower Management Center Configuration Guide, Version 6.3

716
 Firepower Threat Defense High Availability and Scalability
Add a Firepower Threat Defense High Availability Pair

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.

Add a Firepower Threat Defense High Availability Pair

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Network

Defense Admin
Firepower Threat
Defense Virtual

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 312 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.

Firepower Management Center Configuration Guide, Version 6.3

717
 Firepower Threat Defense High Availability and Scalability
Add a Firepower Threat Defense High Availability Pair

• Are either in routed or transparent mode.

• Have the same NTP configuration. See Configure NTP Time Synchronization for Threat Defense, on
page 1131.
• Are fully deployed with no uncommitted changes.
• 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 Devices to the Firepower Management
Center, on page 499.
Step 2 Choose Devices > Device Management.
Step 3 From the Add drop-down menu, choose Add 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.
Note 169.254.0.0/16 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.
Note 169.254.0.0/16 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.

Firepower Management Center Configuration Guide, Version 6.3

718
 Firepower Threat Defense High Availability and Scalability
Configure Optional High Availability Parameters

Step 17 Click OK. This process takes a few minutes as the process synchronizes system data.

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

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Network

Defense Admin
Firepower Threat
Defense Virtual

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 with logical names configured. You might want
to exclude interfaces attached to less critical networks from affecting your failover policy.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device high-availability pair you want to edit, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the High Availability tab.

Step 4 In the Monitored Interfaces area, click the edit icon ( ) 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 icon ( ) 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.

Firepower Management Center Configuration Guide, Version 6.3

719
 Firepower Threat Defense High Availability and Scalability
Edit High Availability Failover Criteria

Step 8 Click OK.

Edit High Availability Failover Criteria

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Network

Defense Admin
Firepower Threat
Defense Virtual

You can customize failover criteria based on your network deployment.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device high-availability pair you want to edit, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Choose High Availability.

Step 4 Next to Failover Trigger Criteria, click the edit icon ( ).

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.
Step 7 Click OK.

Configure Virtual MAC addresses

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Network

Defense Admin
Firepower Threat
Defense Virtual

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
Address, on page 669.
• The Add Interface MAC Address page accessed from the High Availability page; see

Firepower Management Center Configuration Guide, Version 6.3

720
 Firepower Threat Defense High Availability and Scalability
Manage High Availability

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 1 Choose Devices > Device Management.

Step 2 Next to the device high-availability pair you want to edit, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Choose High Availability.

Step 4 Choose the add icon ( )next to Interface Mac Addresses.
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
Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Network

Defense Admin
Firepower Threat
Defense Virtual

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 722

Firepower Management Center Configuration Guide, Version 6.3

721
 Firepower Threat Defense High Availability and Scalability
Refresh node status in a Firepower Threat Defense High Availability pair

Note 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 1 Choose Devices > Device Management.

Step 2 Next to the high availability pair where you want to change the active peer, click the Switch Active Peer icon

( ).
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

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Network

Defense Admin
Firepower Threat
Defense Virtual

Whenever active or standby devices in a high availability pair are rebooted, the Firepower Management Center
may not display accurate high availability status for either device. This is because when theFirepower Threat
Defense reboots, the high availability status is immediately updated on the Firepower Threat Defense and its
corresponding event is sent to the Firepower Management Center. However, the status may not be updated
on the Firepower Management Center because the communication between the Firepower Threat Defense
and the Firepower Management Center is yet to be established.
Communication failures or weak communication channels between the Firepower Management Center and
the Firepower Threat Defense 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 Firepower Management Center even
after a significant time duration.
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.

Note The node refresh operation is available only on a Firepower Threat Defense high availability device being
managed by Firepower Management Center version 6.2.3 or later.

Firepower Management Center Configuration Guide, Version 6.3

722
 Firepower Threat Defense High Availability and Scalability
Suspend and Resume High Availability

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the high availability pair where you want to refresh the node status, click the Refresh HA Node Status
icon ( ).
Step 3 You can:
• Click Yes to refresh the node status of the high availability pair.
• Click No to cancel and return to the Device Management page.

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.

Firepower Management Center Configuration Guide, Version 6.3

723
 Firepower Threat Defense High Availability and Scalability
Replace a Unit

Note Suspending high availability is a temporary state. If you reload a unit, it resumes the high-availability
configuration automatically and negotiates the active/standby state with the peer.

Replace a Unit
If you need to replace a failed unit in a Firepower Threat Defense high availability pair, you must choose the
Force Break option to separate the pair. After you replace or repair the unit, you must then register the device
on the Firepower Management Center and re-establish high availability. The process varies depending on
whether the device is primary or secondary.

Replace a Primary Unit

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Network

Defense Admin
Firepower Threat
Defense Virtual

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 725.
Step 2 Unregister the failed primary Firepower Threat Defense device from the Firepower Management Center; see
Deleting Devices from the Firepower Management Center, on page 501.
Step 3 Register the replacement Firepower Threat Defense to the Firepower Management Center; see Add Devices
to the Firepower Management Center, on page 499.
Step 4 Configure high availability, using the existing secondary/active unit as the primary device and the replacement
device as the secondary/standby device during registration; see Add a Firepower Threat Defense High
Availability Pair, on page 717.

Replace a Secondary Unit

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Network

Defense Admin
Firepower Threat
Defense Virtual

Firepower Management Center Configuration Guide, Version 6.3

724
 Firepower Threat Defense High Availability and Scalability
Separate Units in a High Availability Pair

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 725.
Step 2 Unregister the secondary Firepower Threat Defense device from the Firepower Management Center; see
Deleting Devices from the Firepower Management Center, on page 501.
Step 3 Register the replacement Firepower Threat Defense to the Firepower Management Center; see Add Devices
to the Firepower Management Center, on page 499.
Step 4 Configure high availability, using the existing primary/active unit as the primary device and the replacement
device as the secondary/standby device during registration; see Add a Firepower Threat Defense High
Availability Pair, on page 717.

Separate Units in a High Availability Pair

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Network

Defense Admin
Firepower Threat
Defense Virtual

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.

Tip An exception to this is the flex-config policy. A flex-config policy deployed on the active device may show
a deployment failure after the break HA operation. You must alter and re-deploy the flex-config 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 722

Firepower Management Center Configuration Guide, Version 6.3

725
 Firepower Threat Defense High Availability and Scalability
Unregister a High Availability Pair

Note 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 1 Choose Devices > Device Management.

Step 2 Next to the high-availability pair you want to break, click the Break HA icon ( ).
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

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Network

Defense Admin
Firepower Threat
Defense Virtual

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 1 Choose Devices > Device Management.

Step 2 Next to the high-availability pair you want to unregister, click the Delete icon ( ).
Step 3 Click Yes. The device high availability pair is deleted.
Step 4 On each unit, access the Firepower Threat Defense CLI, and enter the following command:
configure high-availability disable

Firepower Management Center Configuration Guide, Version 6.3

726
 Firepower Threat Defense High Availability and Scalability
Monitoring High Availability

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

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Network

Defense Admin
Firepower Threat
Defense Virtual

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 1 Choose Devices > Device Management.

Step 2 Next to the device high-availability pair you want to edit, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Choose Summary.

Step 4 Under General, click the view icon ( ).

View Stateful Failover Statistics

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Network

Defense Admin
Firepower Threat
Defense Virtual

Firepower Management Center Configuration Guide, Version 6.3

727
 Firepower Threat Defense High Availability and Scalability
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 1 Choose Devices > Device Management.

Step 2 Next to the device high-availability pair you want to edit, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Choose High Availability.

Step 4 Under Stateful Failover Link, click the view icon ( ).
Step 5 Choose a device to view statistics.

Firepower Management Center Configuration Guide, Version 6.3

728
 CHAPTER 35
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
733.

• About Clustering on the Firepower 4100/9300 Chassis, on page 729

• Firepower Threat Defense Features and Clustering, on page 733
• Licenses for Clustering, on page 737
• Requirements and Prerequisites for Clustering, on page 737
• Clustering Guidelines and Limitations, on page 738
• Configure Clustering, on page 742
• Manage Cluster Members, on page 749
• FMC: Monitoring the Cluster, on page 753
• Reference for Clustering, on page 754
• History for Clustering, on page 759

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:
• Creates a cluster-control link (by default, port-channel 48) for unit-to-unit communication. 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.
• Creates the cluster bootstrap configuration within the application.
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.

Firepower Management Center Configuration Guide, Version 6.3

729
 Firepower Threat Defense High Availability and Scalability
Bootstrap Configuration

• 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 754.

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 master unit. The master unit is determined automatically. All other members
are slave units.
You must perform all configuration on the master unit only; the configuration is then replicated to the slave
units.
Some features do not scale in a cluster, and the master unit handles all traffic for those features. See Centralized
Features for Clustering, on page 734.

Cluster Control Link

The cluster control link is automatically created using the Port-channel 48 interface. 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.
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:

Firepower Management Center Configuration Guide, Version 6.3

730
 Firepower Threat Defense High Availability and Scalability
Cluster Control Link Redundancy for Inter-Chassis Clustering

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

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.

Firepower Management Center Configuration Guide, Version 6.3

731
 Firepower Threat Defense High Availability and Scalability
Cluster Control Link Network

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. You can customize this IP address when you
deploy the cluster. 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.
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 master unit. You also configure a range of addresses so that each unit, including the
current master, can use a Local address from the range. The Main cluster IP address provides consistent
diagnostic access to an address; when a master unit changes, the Main cluster IP address moves to the new
master unit, so access to the cluster continues seamlessly. For outbound management traffic such as TFTP or
syslog, each unit, including the master 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

Firepower Management Center Configuration Guide, Version 6.3

732
 Firepower Threat Defense High Availability and Scalability
Connecting to a VSS or vPC

is assigned to the BVI, not to the bridge group member interface. The EtherChannel inherently provides load
balancing as part of basic operation.

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 master
unit, and changes are automatically synced to all other units in the cluster.

Firepower Threat Defense Features and Clustering

Some FTD features are not supported with clustering, and some are only supported on the master 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.

Firepower Management Center Configuration Guide, Version 6.3

733
 Firepower Threat Defense High Availability and Scalability
Centralized Features for Clustering

• Remote access VPN (SSL VPN and IPsec VPN)

• DHCP client, server, and proxy. DHCP relay is supported.
• High Availability
• Integrated Routing and Bridging
• Dead Connection Detection (DCD)

Centralized Features for Clustering

The following features are only supported on the master unit, and are not scaled for the cluster.

Note Traffic for centralized features is forwarded from member units to the master unit over the cluster control
link.
If you use the rebalancing feature, traffic for centralized features may be rebalanced to non-master units before
the traffic is classified as a centralized feature; if this occurs, the traffic is then sent back to the master unit.
For centralized features, if the master unit fails, all connections are dropped, and you have to re-establish the
connections on the new master 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 master unit, and routes are learned through the master unit and replicated
to secondaries. If a routing packet arrives at a slave, it is redirected to the master unit.

Firepower Management Center Configuration Guide, Version 6.3

734
 Firepower Threat Defense High Availability and Scalability
NAT and Clustering

Figure 21: Dynamic Routing

After the slave members learn the routes from the master unit, each unit makes forwarding decisions
independently.
The OSPF LSA database is not synchronized from the master unit to slave units. If there is a master 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.

NAT and Clustering

NAT can affect the overall throughput of the cluster. Inbound and outbound NAT packets can be sent to
different Firepower Threat Defense devices 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 Firepower Threat Defense device 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:
• NAT pool address distribution for dynamic PAT—The master unit evenly pre-distributes addresses across
the cluster. If a member receives a connection and they have no addresses left, then the connection is
dropped even if other members still have addresses available. Make sure to include at least as many NAT
addresses as there are units in the cluster to ensure that each unit receives an address.
• No round-robin—Round-robin for a PAT pool is not supported with clustering.
• Dynamic NAT xlates managed by the master unit—The master unit maintains and replicates the xlate
table to slave units. When a slave unit receives a connection that requires dynamic NAT, and the xlate
is not in the table, it requests the xlate from the master unit. The slave unit owns the connection.
• No static PAT for the following inspections—
• FTP
• RSH
• SQLNET

Firepower Management Center Configuration Guide, Version 6.3

735
 Firepower Threat Defense High Availability and Scalability
SIP Inspection and Clustering

• TFTP
• XDMCP
• SIP

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.

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.

SNMP and Clustering

An SNMP agent polls each individual Firepower Threat Defense device by its Diagnostic interface Local IP
address. You cannot poll consolidated data for the cluster.
You should always use the Local address, and not the Main cluster IP address for SNMP polling. If the SNMP
agent polls the Main cluster IP address, if a new master is elected, the poll to the new master unit will fail.

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.

Cisco TrustSec and Clustering

Only the master unit learns security group tag (SGT) information. The master unit then populates the SGT to
slaves, and slaves 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 master unit supports VPN connections.

Firepower Management Center Configuration Guide, Version 6.3

736
 Firepower Threat Defense High Availability and Scalability
Licenses for Clustering

Note Remote access VPN is not supported with clustering.

VPN functionality is limited to the master unit and does not take advantage of the cluster high availability
capabilities. If the master unit fails, all existing VPN connections are lost, and VPN users will see a disruption
in service. When a new master 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 master unit.
VPN-related keys and certificates are replicated to all units.

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.
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.

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 slave units to leave the cluster and then rejoin.

Requirements and Prerequisites for Clustering

Cluster Model Support
• Firepower 9300—You can include up to 6 units in the cluster in up to 6 chassis. Supports intra-chassis
and inter-chassis clustering.
• Firepower 4100 series—Supported for up to 6 units using inter-chassis clustering.

Inter-Chassis Clustering Hardware and Software Requirements

All chassis in a cluster:
• For the Firepower 4100 series: All chassis must be the same model. For the Firepower 9300: All security
modules 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.
• 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

Firepower Management Center Configuration Guide, Version 6.3

737
 Firepower Threat Defense High Availability and Scalability
Clustering Guidelines and Limitations

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 slave units, and ending with the master.
• 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.

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 a list of supported switches, see Cisco FXOS Compatibility.

Clustering Guidelines and Limitations

Switches for Inter-Chassis Clustering
• For the ASR 9006, if you want to set a non-default MTU, set the ASR 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 ASR IPv4 MTU.
• 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.
• 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. 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.
• 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:

Firepower Management Center Configuration Guide, Version 6.3

738
Firepower Threat Defense High Availability and Scalability
Clustering Guidelines and Limitations

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.

EtherChannels for Inter-Chassis Clustering

• For connecting switches, set the EtherChannel mode to Active; On mode is not supported on the Firepower
4100/9300 chassis, even for the cluster control link.
• FXOS EtherChannels have the LACP rate set to fast by default. 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.

• 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 master 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.

Firepower Management Center Configuration Guide, Version 6.3

739
 Firepower Threat Defense High Availability and Scalability
Clustering Guidelines and Limitations

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

Firepower Management Center Configuration Guide, Version 6.3

740
Firepower Threat Defense High Availability and Scalability
Clustering Guidelines and Limitations

Additional Guidelines
• When adding a unit to an existing cluster, or when reloading a unit, there will be a temporary, limited
packet/connection drop; this is expected behavior. In some cases, the dropped packets can hang
connections; for example, dropping a FIN/ACK packet for an FTP connection will make the FTP client
hang. In this case, you need to reestablish the FTP connection.
• If you use a Windows 2003 server connected to a Spanned EtherChannel interface, when the syslog
server port is down, and the server does not throttle ICMP error messages, then large numbers of ICMP
messages are sent back to the cluster. These messages can result in some units of the cluster experiencing
high CPU, which can affect performance. We recommend that you throttle ICMP error messages.
• We recommend connecting EtherChannels to a VSS or vPC for redundancy.
• Within a chassis, you cannot cluster some security modules and run other security modules in standalone
mode; you must include all security modules in the cluster.

Firepower Management Center Configuration Guide, Version 6.3

741
 Firepower Threat Defense High Availability and Scalability
Configure Clustering

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

You can add a single Firepower 9300 chassis as an intra-chassis cluster, or add 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.

Before you begin

• You must enable clustering for all 3 module slots in a Firepower 9300 chassis, even if you do not have
a module installed. If you do not configure all 3 modules, the cluster will not come up.
• 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.

Procedure

Step 1 Add at least one Data type interface or EtherChannel (also known as a port-channel) before you deploy the
cluster.
You can also add data interfaces to the cluster after you deploy it.
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

Firepower Management Center Configuration Guide, Version 6.3

742
Firepower Threat Defense High Availability and Scalability
Create a Firepower Threat Defense Cluster

into a single EtherChannel on the switch. See Clustering Guidelines and Limitations, on page 738 for more
information about EtherChannels for inter-chassis clustering.

Step 2 Add a Management type interface or EtherChannel.

For inter-chassis clustering, add the same Management interface on each chassis. 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 (and that appears at the top of the Interfaces tab as MGMT).

Step 3 For inter-chassis clustering, add a member interface to port-channel 48, which is used as the cluster control
link.
If you do not include a member interface, then when you deploy the logical device, the Firepower Chassis
Manager assumes that this cluster is an intra-chassis cluster and does not show the Chassis ID field. 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 738 for more information about EtherChannels for inter-chassis clustering.

Step 4 (Optional) Add a Firepower-eventing interface.

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 5 Choose Logical Devices.

The Logical Devices page shows a list of logical devices on the chassis.

Step 6 Click Add Device.

The Add Device dialog box appears.

Step 7 For the Device Name, provide a name for the logical device.
This name is used by the Firepower 4100/9300 chassis supervisor to configure management settings and to
assign interfaces; it is not the device name used in the security module/engine configuration.

Step 8 For the Template, choose Cisco Firepower Threat Defense.

Step 9 Choose the Firepower Threat Defense Image Version.
Step 10 For the Device Mode, click the Cluster radio button.
Step 11 Click the Create New Cluster radio button.
Step 12 Click OK.
If you have any standalone devices configured, you are prompted to replace them with a new cluster. You
see the Provisioning - device name window.
All interfaces are assigned to the cluster by default; for inter-chassis clustering . Hardware Bypass-capable
ports are shown with the following icon: . 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. Hardware Bypass ports are not supported
in inter-chassis clustering because they are not supported as EtherChannel members.

Step 13 Click the device icon in the center of the screen.

Firepower Management Center Configuration Guide, Version 6.3

743
 Firepower Threat Defense High Availability and Scalability
Create a Firepower Threat Defense Cluster

The Cisco Firepower Threat Defense Configuration dialog box appears.

Step 14 On the Cluster Information tab, complete the following:

a) In the Chassis ID field, enter a chassis ID. Each chassis in the cluster must use a unique ID.
b) In the Site ID field, 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.
c) 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.
d) 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.
e) Select the management interface to use with the logical device from the Management Interface drop-down
list.
If you assign a Hardware Bypass-capable interface as the Management interface, you see a warning
message to make sure your assignment is intentional.

Step 15 On the Settings tab, 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) In the Password field, enter a password for the admin user on the cluster.
c) In the Firepower Management Center IP field, enter the IP address of the managing Firepower
Management Center.
d) In the Search Domains field, enter a comma-separated list of search domains for the management network.
e) From the Firewall Mode drop-down list, choose Transparent or Routed.
f) In the DNS Servers field, enter a comma-separated list of DNS servers that the FTD device should use
on the management network.
g) In the Fully Qualified Hostname field, enter a fully qualified name for the FTD device.
h) 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 16 On the Interface Information tab, 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.

a) In the Management IP field, configure an IP address.

Specify an IP address on the same network for each module.
b) Enter a Network Mask or Prefix Length.
c) Enter a Network Gateway address.

Firepower Management Center Configuration Guide, Version 6.3

744
 Firepower Threat Defense High Availability and Scalability
Add More Cluster Members

Step 17 On the Agreement tab, read and accept the end user license agreement (EULA).
Step 18 Click OK to close the Cisco Firepower Threat Defense Configuration dialog box.
Step 19 Click Save.
The Firepower 4100/9300 chassis supervisor deploys the cluster by downloading the specified software version
and pushing the cluster bootstrap configuration and management interface settings to each security module.

Step 20 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 Join an Existing Cluster.
d) Click the Copy config check box, and click OK. If you uncheck this check box, you must manually enter
the settings to match the first chassis configuration.
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. 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.
• CCL Subnet IP—By default, the cluster control link uses the 127.2.0.0/16 network. However, some
networking deployments do not allow 127.2.0.0/16 traffic to pass. In this case, specify any /16 network
address on a unique network for the cluster, except for loopback (127.0.0.0/8) and multicast
(224.0.0.0/4) addresses. If you set the value to 0.0.0.0, then the default network is used. The chassis
auto-generates the cluster control link interface IP address for each unit based on the chassis ID and
slot ID: a.b.chassis_id.slot_id.

Click OK.
g) Click Save.
Step 21 Add the master 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 slave units.

Add More Cluster Members

Add or replace a FTD cluster member in an existing cluster.

Firepower Management Center Configuration Guide, Version 6.3

745
 Firepower Threat Defense High Availability and Scalability
Add More Cluster Members

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 member 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.
Step 3 Connect to the Firepower Chassis Manager on the new chassis, and click Add Device.
Step 4 For the Device Name, provide a name for the logical device.
Step 5 For the Template, choose Cisco Firepower Threat Defense.
Step 6 For the Image Version, choose the FTD software version.
Step 7 For the Device Mode, click the Cluster radio button.
Step 8 Choose Join an Existing Cluster.
Step 9 Click the Copy config check box, and click OK. If you uncheck this check box, you must manually enter the
settings to match the first chassis configuration.
Step 10 In the Copy Cluster Details box, paste in the cluster configuration from the first chassis, and click OK.
Step 11 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 12 Click Save.

Step 13 In the Firepower Management Center, choose Devices > Device Management, and select the Add > Add
Device to add the new logical device.

Firepower Management Center Configuration Guide, Version 6.3

746
 Firepower Threat Defense High Availability and Scalability
FMC: Add a Cluster

Step 14 Choose Add > Add Cluster.

Step 15 Choose the current Master device from the drop-down list.
When you choose a master device that is already in a cluster, then the existing cluster name is auto-filled, and
all eligible slave devices are added to the Slave Devices box, including the new unit you just added to the
FMC.

Step 16 Click Add, and then Deploy.

The cluster is updated to include the new member(s).

FMC: Add a Cluster

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD on the Any Access Admin

Firepower 4100 and Administrator
9300 Network Admin

Add one of the cluster units as a new device to the Firepower Management Center; the FMC auto-detects all
other cluster members.

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 master 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 one of the
cluster units using the management IP address you assigned when you deployed the cluster.
We recommend adding the master unit for the best performance, but you can add any unit.
The FMC identifies and registers the master unit, and then registers all slave units. If the master 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. A unit that is currently registering shows the loading icon. You can monitor cluster unit registration by
clicking the system status icon and choosing the Tasks tab. The FMC updates the Cluster Registration task
as each unit registers. If any units fail to register, see Reconcile Cluster Members, on page 752.

Firepower Management Center Configuration Guide, Version 6.3

747
 Firepower Threat Defense High Availability and Scalability
FMC: Configure Data and Diagnostic Interfaces

Step 2 Configure device-specific settings by clicking the edit icon ( ) for the cluster; you can only configure the
cluster as a whole, and not member units in the cluster.
Step 3 On the Devices > Device Management > Cluster tab, you see General, License, System, and Health settings.
• In the General area, view cluster status by clicking the Current Cluster Summary link to open the
Cluster Status dialog box. The Cluster Status dialog box also lets you retry slave registration by clicking
Reconcile.

• In the License area, click the edit icon ( ) to set license entitlements.

Step 4 On the Devices > Device Management > Devices tab, you can choose each member in the cluster from the
top right drop-down menu.
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.

FMC: Configure Data and Diagnostic Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Access Admin

Defense on the Administrator
Firepower 4100 and Network Admin
9300

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.
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 the edit icon ( ) next to the cluster.
Step 2 Click the Interfaces tab.
Step 3 (Optional) Configure VLAN subinterfaces on the interface. The rest of this procedure applies to the
subinterfaces.
Step 4 Click the edit icon ( ) for the data interface.
Step 5 For inter-chassis clusters, set a manual global MAC address for the EtherChannel.

Firepower Management Center Configuration Guide, Version 6.3

748
Firepower Threat Defense High Availability and Scalability
Manage Cluster Members

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 master unit. If
you do not configure a MAC address, then if the master unit changes, the new master unit uses a new MAC
address for the interface, which can cause a temporary network outage.
a) Click the Advanced tab.
The Information tab is selected.
b) 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.

Step 6 Configure the name, IP address, and other parameters.

Step 7 Click OK. Repeat the above steps for other data interfaces.
Step 8 (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.
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 the edit icon ( ) for the Diagnostic interface.
c) On the IPv4 tab, enter the Virtual IP Address and mask. This IP address is a fixed address for the cluster,
and always belongs to the current master unit.
d) From the IPv4 Address Pool drop-down list, choose the address pool you created.
e) On the IPv6 > Basic tab, from the IPv6 Address Pool drop-down list, choose the address pool you created.
f) Configure other interface settings as normal.
Step 9 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Manage Cluster Members

After you deploy the cluster, you can change the configuration and manage cluster members.

Firepower Management Center Configuration Guide, Version 6.3

749
 Firepower Threat Defense High Availability and Scalability
Add a New Cluster Member

Add a New Cluster Member

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Access Admin

Defense on the Administrator
Firepower 4100 and Network Admin
9300

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 (Devices > Device Management > Cluster tab > General area > Current
Cluster Summary link)—A unit that is joining the cluster on the chassis shows "Joining cluster..." After
it joins the cluster, the FMC attempts to register it, and the status changes to "Available for Registration".
After it completes registration, the status changes to "In Sync." If the registration fails, the unit will stay
at "Available for Registration". In this case, force a re-registration by clicking Reconcile.
• System status icon > Tasks tab—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.

Replace a Cluster Member

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD on the Any Access Admin

Firepower 4100 and Administrator
9300 Network Admin

You can replace a cluster member in an existing cluster. The Firepower Management Center auto-detects the
replacement unit. However, you must manually delete the old cluster member in the Firepower Management

Firepower Management Center Configuration Guide, Version 6.3

750
Firepower Threat Defense High Availability and Scalability
Replace a Cluster Member

Center. 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 750.
For information about all of the below steps, see the FXOS configuration guide.
a) Use the configuration export feature to export an XML file containing logical device and platform
configuration settings for your Firepower 4100/9300 chassis.
b) Import the configuration file to the replacement chassis.
c) Accept the license agreement.
d) If necessary, upgrade the logical device application instance version to match the rest of the cluster.

Step 2 In the Firepower Management Center, choose Devices > Device Management, and click the delete icon ( )
next to the old unit.
Step 3 Confirm that you want to delete the unit.
The unit is removed from the cluster and from the FMC devices list.

Step 4 The new or reinitialized cluster member is added automatically. To monitor the registration of the replacement
unit, view the following:
• Cluster Status dialog box (Devices > Device Management > Cluster tab > General area > Current
Cluster Summary link)—A unit that is joining the cluster on the chassis shows "Joining cluster..." After
it joins the cluster, the FMC attempts to register it, and the status changes to "Available for Registration".
After it completes registration, the status changes to "In Sync." If the registration fails, the unit will stay
at "Available for Registration". In this case, force a re-registration by clicking Reconcile.
• System status icon > Tasks tab—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.

Firepower Management Center Configuration Guide, Version 6.3

751
 Firepower Threat Defense High Availability and Scalability
Delete a Slave Member

Delete a Slave Member

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD on the Any Access Admin

Firepower 4100 and Administrator
9300 Network Admin

If you need to 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; even though you removed it from the FMC, it will still be an operational part of the cluster,
which can cause problems if it became the master unit and the FMC can no longer manage it.

Procedure

Step 1 Make sure the unit is ready to be deleted from the FMC.

a) Choose Devices > Device Management, and click the edit icon ( ) for the cluster.
b) On the Devices > Device Management > Cluster tab > General area, click the Current Cluster Summary
link to open the Cluster Status dialog box.
c) Ensure that the devices you want to delete are in the "Available for Deletion" state.
If the status is stale, click Reconcile to force an update.

Step 2 In the FMC, choose Devices > Device Management, and click the delete icon ( ) next to the slave unit.
Step 3 Confirm that you want to delete the unit.
The unit is removed from the cluster and from the FMC devices list.

Reconcile Cluster Members

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Access Admin

Defense on the Administrator
Firepower 4100 and Network Admin
9300

If a cluster member fails to register, you can reconcile the cluster membership from the chassis to the Firepower
Management Center. For example, a slave 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, and click the edit icon ( ) for the cluster.

Firepower Management Center Configuration Guide, Version 6.3

752
 Firepower Threat Defense High Availability and Scalability
Rejoin the Cluster

Step 2 On the Cluster tab > General area, click the Current Cluster Summary link to open the Cluster Status
dialog box.
Step 3 Click Reconcile.
For more information about the cluster status, see FMC: Monitoring the Cluster, on page 753.

Rejoin the Cluster

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Access Admin

Defense on the Administrator
Firepower 4100 and Network Admin
9300

If a unit was removed from the cluster, for example for a failed interface, you must manually rejoin the cluster
by accessing the unit CLI. Make sure the failure is resolved before you try to rejoin the cluster. See Rejoining
the Cluster, on page 756 for more information about why a unit can be removed from a cluster.

Procedure

Step 1 Access the CLI of the unit that needs to rejoin the cluster, either from the console port or using SSH to the
Management interface. Log in with the username admin and the password you set during initial setup.
Step 2 Enable clustering:
cluster enable

FMC: Monitoring the Cluster

You can monitor the cluster in Firepower Management Center and at the FTD CLI.
• Devices > Device Management > Cluster tab > General area > Current Cluster Summary link >
Cluster Status dialog box.
Cluster member states include:
• In Sync.—The unit is registered with the FMC.
• Available for 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.
• Available for Deletion—The unit is registered with the FMC, but is no longer part of the cluster
and should be deleted.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

753
 Firepower Threat Defense High Availability and Scalability
Reference for Clustering

To refresh this dialog box, close and reopen it.

• System status icon > Tasks tab.
The Tasks tab shows updates of the Cluster Registration task as each unit registers.
• Devices > Device Management > cluster_name.
When you expand the cluster on the devices listing page, you can see all member units, including the
master unit shown with "(master)" 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.

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.

For example, for TCP throughput, the Firepower 9300 with 3 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.

Master Unit Election

Members of the cluster communicate over the cluster control link to elect a master 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 master.

Firepower Management Center Configuration Guide, Version 6.3

754
 Firepower Threat Defense High Availability and Scalability
High Availability Within the Cluster

4. If a unit later joins the cluster with a higher priority, it does not automatically become the master unit; the
existing master unit always remains as the master unless it stops responding, at which point a new master
unit is elected.

Note You can manually force a unit to become the master. For centralized features, if you force a master unit change,
then all connections are dropped, and you have to re-establish the connections on the new master 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.

Unit Health Monitoring

The master unit monitors every slave unit by sending keepalive messages over the cluster control link
periodically. Each slave unit monitors the master unit using the same mechanism. If the unit health check
fails, the unit is removed from the cluster.

Interface Monitoring
Each unit monitors the link status of all hardware interfaces in use, and reports status changes to the master
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.
When you enable health monitoring, 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.

Firepower Management Center Configuration Guide, Version 6.3

755
 Firepower Threat Defense High Availability and Scalability
Status After Failure

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 cluster link.
If the master unit fails, then another member of the cluster with the highest priority (lowest number) becomes
the master unit.
The Firepower Threat Defense device automatically tries to rejoin the cluster, depending on the failure event.

Note When the Firepower Threat Defense device 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—After you resolve the problem with the cluster control link, you must manually
rejoin the cluster by re-enabling clustering.
• Failed data interface—The FTD application 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.

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 67: Features Replicated Across the Cluster

Traffic State Support Notes

Up time Yes Keeps track of the system up time.

ARP Table Yes —

Firepower Management Center Configuration Guide, Version 6.3

756
 Firepower Threat Defense High Availability and Scalability
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 master 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

Firepower Management Center Configuration Guide, Version 6.3

757
 Firepower Threat Defense High Availability and Scalability
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.

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.

1. The SYN packet originates from the client and is delivered to one Firepower Threat Defense device (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 Firepower Threat Defense
device (based on the load balancing method). This Firepower Threat Defense device 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.

Firepower Management Center Configuration Guide, Version 6.3

758
 Firepower Threat Defense High Availability and Scalability
History for Clustering

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.

History for Clustering

Feature Version Details

Improved Firepower Threat Defense cluster 6.3.0 You can now add any unit of a cluster to
addition to the Firepower Management the Firepower Management Center, and the
Center other cluster units are detected
automatically. Formerly, you had to add
each cluster unit as a separate device, and
then group them into a cluster in the
Management Center. Adding a cluster unit
is also now automatic. Note that you must
delete a unit manually.
New/Modified screens:
Devices > Device Management > Add
drop-down menu > Device > Add Device
dialog box
Devices > Device Management > Cluster
tab > General area > Cluster Registration
Status > Current Cluster Summary link
> Cluster Status dialog box
Supported platforms: Firepower 4100/9300

Support for Site-to-Site VPN with 6.2.3.3 You can now configure site-to-site VPN
clustering as a centralized feature with clustering. Site-to-site VPN is a
centralized feature; only the master unit
supports VPN connections.
Supported platforms: Firepower 4100/9300

Firepower Management Center Configuration Guide, Version 6.3

759
 Firepower Threat Defense High Availability and Scalability
History for Clustering

Feature Version Details

Automatically rejoin the cluster after an 6.2.3 Formerly, many internal error conditions
internal failure caused a cluster unit to be removed from
the cluster, and you were required to
manually rejoin the cluster after resolving
the issue. Now, a unit will attempt to rejoin
the cluster automatically at the following
intervals: 5 minutes, 10 minutes, and then
20 minutes. Internal failures include:
application sync timeout; inconsistent
application statuses; and so on.
New/Modified command: show cluster
info auto-join
No modified screens.
Supported platforms: Firepower Threat
Defense on the Firepower 4100/9300

Inter-chassis clustering for 6 modules; 6.2.0 With FXOS 2.1.1, you can now enable
Firepower 4100 support inter-chassis clustering on the Firepower
9300 and 4100. You can include up to 6
units in up to 6 chassis.
Note Inter-site clustering is now
supported using FlexConfig
only.

No modified screens.
Supported platforms: Firepower Threat
Defense on the Firepower 4100/9300

Intra-chassis Clustering for the Firepower 6.0.1 You can cluster up to 3 security modules
9300 within the Firepower 9300 chassis. All
modules in the chassis must belong to the
cluster.
New/Modified screens:
Devices > Device Management > Add >
Add Cluster
Devices > Device Management > Cluster
Supported platforms: Firepower Threat
Defense on the Firepower 9300

Firepower Management Center Configuration Guide, Version 6.3

760
PA R T XI
Firepower Threat Defense Routing
• Routing Overview for Firepower Threat Defense, on page 763
• Static and Default Routes for Firepower Threat Defense, on page 773
• OSPF for Firepower Threat Defense, on page 777
• BGP for Firepower Threat Defense, on page 803
• RIP for Firepower Threat Defense, on page 819
• Multicast Routing for Firepower Threat Defense, on page 825
 CHAPTER 36
Routing Overview for Firepower Threat Defense
This chapter describes underlying concepts of how routing behaves within the Firepower Threat Defense.
• Path Determination, on page 763
• Supported Route Types, on page 764
• Supported Internet Protocols for Routing, on page 765
• Routing Table, on page 766
• Routing Table for Management Traffic, on page 769
• Equal-Cost Multi-Path (ECMP) Routing, on page 770
• About Route Maps, on page 770

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.

Firepower Management Center Configuration Guide, Version 6.3

763
 Firepower Threat Defense Routing
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.

Firepower Management Center Configuration Guide, Version 6.3

764
 Firepower Threat Defense Routing
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).

Firepower Management Center Configuration Guide, Version 6.3

765
 Firepower Threat Defense Routing
Routing Table

Routing Table
This section describes the routing table.

How the Routing Table Is Populated

The Firepower Threat Defense device routing table can be populated by statically defined routes, directly
connected routes, and routes discovered by the dynamic routing protocols. Because the Firepower Threat
Defense device 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 Firepower Threat Defense device 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 Firepower Threat Defense device 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

Firepower Management Center Configuration Guide, Version 6.3

766
 Firepower Threat Defense Routing
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 68: 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

Firepower Management Center Configuration Guide, Version 6.3

767
 Firepower Threat Defense Routing
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 master unit, and routes are learned through the master unit and replicated
to slaves. If a routing packet arrives at a slave, it is redirected to the master unit.

Firepower Management Center Configuration Guide, Version 6.3

768
 Firepower Threat Defense Routing
Routing Table for Management Traffic

Figure 22: Dynamic Routing in Clustering

After the slave members learn the routes from the master unit, each unit makes forwarding decisions
independently.
The OSPF LSA database is not synchronized from the master unit to slave units. If there is a master 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

As a standard security practice, it is often necessary to segregate and isolate Management traffic from data
traffic. To achieve this isolation, the FTD uses a separate routing table for management-only traffic vs. data
traffic.
The Management routing table supports dynamic routing separate from the data interface routing table. A
given dynamic routing process must run on either the management-only interface or the data interface; you
cannot mix both types.
For all features that open a remote file using HTTP, SCP, TFTP and so on, if you do not specify the interface,
then the FTD checks the management-only routing table; if there are no matches, it then checks the data
routing table.

Firepower Management Center Configuration Guide, Version 6.3

769
 Firepower Threat Defense Routing
Equal-Cost Multi-Path (ECMP) Routing

For all other features, if you do not specify the interface, then the FTD checks the data routing table; if there
are no matches, it then checks the management-only routing table. For example ping, DNS, DHCP, and so
on.
If you specify the interface when using a feature, then the FTD checks the correct routing table for routes for
that interface. For example, if the interface is a management-only interface, then the FTD checks the
management-only routing table. In this case, the ASA does not check the data routing table as a backup,
because there are no routes in the data routing table using this interface.
If you use a feature that defaults to the incorrect routing table, then you should specify the interface you want
to use. For example, if you use the ping command, which defaults to the data routing table, but you know
that the destination is on a management-only network, then you should specify the interface. In some cases,
you cannot rely on the FTD to fall back to the correct routing table; for example, if the default routing table
includes a default route, then the traffic will find a match and will never fall back to the other routing table.
Management-only interfaces include any Diagnostic x/x interfaces as well as any interfaces that you have
configured to be management-only.

Note This routing table does not affect the special FTD Management logical interface that it uses to communicate
with the FMC; that interface has its own routing table. The Diagnostic logical interface, on the other hand,
uses the management-only routing table described in this section.

Equal-Cost Multi-Path (ECMP) Routing

The Firepower Threat Defense device supports Equal-Cost Multi-Path (ECMP) routing.
You can have up to 3 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
route for 0.0.0.0 0.0.0.0 through outside to 10.1.1.3
route for 0.0.0.0 0.0.0.0 through outside to 10.1.1.4

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 is not supported across multiple interfaces, so you cannot define a route to the same destination on a
different interface. The following route is disallowed when configured with any of the routes above:
route for 0.0.0.0 0.0.0.0 through outside2 to 10.2.1.1

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:

Firepower Management Center Configuration Guide, Version 6.3

770
 Firepower Threat Defense Routing
Permit and Deny Clauses

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

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).

Firepower Management Center Configuration Guide, Version 6.3

771
 Firepower Threat Defense Routing
Match and Set Clause Values

• 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).

Firepower Management Center Configuration Guide, Version 6.3

772
 CHAPTER 37
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 773
• Guidelines for Static and Default Routes, on page 775
• Add a Static Route, on page 775

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

773
 Firepower Threat Defense Routing
Route to null0 Interface to “Black Hole” Unwanted Traffic

• You are using a feature that does not support dynamic routing protocols.

Route to null0 Interface to “Black Hole” 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 into a “black hole” 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 770.
• 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
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 MAC Address vs. Route Lookups, on page 582
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

Firepower Management Center Configuration Guide, Version 6.3

774
 Firepower Threat Defense Routing
Guidelines for Static and Default Routes

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.

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
In clustering, static route monitoring is only supported on the primary unit.

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.

Firepower Management Center Configuration Guide, Version 6.3

775
 Firepower Threat Defense Routing
Add a Static Route

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Click the Routing tab.
Step 3 Select Static Route from the table of contents.
Step 4 Click Add Routes.
Step 5 Click the IPv4 or IPv6 radio button depending on the type of static route that you are adding.
Step 6 Choose the Interface to which this static route applies.
For transparent mode, choose a bridge group member interface name. For routed mode with bridge groups,
you can choose either the bridge group member interface for the BVI name. To “black hole” unwanted traffic,
choose the Null0 interface.

Step 7 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.

Step 8 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.
Step 9 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 10 (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 11 (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 432.

Step 12 Click Ok.

Firepower Management Center Configuration Guide, Version 6.3

776
 CHAPTER 38
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 777
• Guidelines for OSPF, on page 780
• Configure OSPFv2, on page 781
• Configure OSPFv3, on page 792

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.

About OSPF
OSPF is an interior gateway routing protocol that uses link states rather than distance vectors for path selection.
OSPF propagates link-state advertisements rather than routing table updates. Because only LSAs are exchanged
instead of the entire routing tables, OSPF networks converge more quickly than RIP networks.
OSPF uses a link-state algorithm to build and calculate the shortest path to all known destinations. Each router
in an OSPF area contains an identical link-state database, which is a list of each of the router usable interfaces
and reachable neighbors.
The advantages of OSPF over RIP include the following:
• OSPF link-state database updates are sent less frequently than RIP updates, and the link-state database
is updated instantly, rather than gradually, as stale information is timed out.
• Routing decisions are based on cost, which is an indication of the overhead required to send packets
across a certain interface. The Firepower Threat Defense device calculates the cost of an interface based
on link bandwidth rather than the number of hops to the destination. The cost can be configured to specify
preferred paths.

The disadvantage of shortest path first algorithms is that they require a lot of CPU cycles and memory.
The Firepower Threat Defense device can run two processes of OSPF protocol simultaneously on different
sets of interfaces. You might want to run two processes if you have interfaces that use the same IP addresses
(NAT allows these interfaces to coexist, but OSPF does not allow overlapping addresses). Or you might want

Firepower Management Center Configuration Guide, Version 6.3

777
 Firepower Threat Defense Routing
About OSPF

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.

Firepower Management Center Configuration Guide, Version 6.3

778
 Firepower Threat Defense Routing
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 779.
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.

Firepower Management Center Configuration Guide, Version 6.3

779
 Firepower Threat Defense Routing
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.

Guidelines for OSPF

Firewall Mode Guidelines
OSPF supports routed firewall mode only. OSPF does not support transparent firewall mode.

High Availability Guidelines

OSPFv2 and OSPFv3 support Stateful High Availability.

IPv6 Guidelines
• OSPFv2 does not support IPv6.
• OSPFv3 supports IPv6.
• OSPFv3 uses IPv6 for authentication.
• The Firepower Threat Defense device installs OSPFv3 routes into the IPv6 RIB, provided it is the best
route.

Clustering Guidelines
• OSPFv3 encryption is not supported. An error message appears if you try to configure OSPFv3 encryption
in a clustering environment.
• In Spanned interface mode, dynamic routing is not supported on management-only interfaces.

Firepower Management Center Configuration Guide, Version 6.3

780
 Firepower Threat Defense Routing
Configure OSPFv2

• When a master role change occurs in the cluster, the following behavior occurs:
• In spanned interface mode, the router process is active only on the master unit and is in a suspended
state on the slave units. Each cluster unit has the same router ID because the configuration has been
synchronized from the master 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 tab 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.

Additional Guidelines
• OSPFv2 and OSPFv3 support multiple instances on an interface.
• OSPFv3 supports encryption through ESP headers in a non-clustered environment.
• OSPFv3 supports Non-Payload Encryption.
• OSPFv2 supports Cisco NSF Graceful Restart and IETF NSF Graceful Restart mechanisms as defined
in RFCs 4811, 4812 & 3623 respectively.
• OSPFv3 supports Graceful Restart mechanism as defined in RFC 5187.
• There is a limit to the number of intra area (type 1) routes that can be distributed. For these routes, a
single type-1 LSA contains all prefixes. Because the system has a limit of 35 KB for packet size, 3000
routes result in a packet that exceeds the limit. Consider 2900 type 1 routes to be the maximum number
supported.

Configure OSPFv2
This section describes the tasks involved in configuring an OSPFv2 routing process.

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.

Firepower Management Center Configuration Guide, Version 6.3

781
 Firepower Threat Defense Routing
Configure OSPF Areas, Ranges, and Virtual Links

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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPF.
Step 3 Select Process 1. You can enable up to two OSPF process instances for each context. You must chose an
OSPF process to be able to configure the Area parameters.
Step 4 Chose 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 777 for a description of the OSPF
roles.
Step 5 Select the Area tab, and click Add.

You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.

Step 6 Configure the following area options for each OSPF process:
• OSPF Process—Choose 1 or 2.
• 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 to 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 the add icon ( )
to add a new network object. See Network Objects, on page 371 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.

Firepower Management Center Configuration Guide, Version 6.3

782
Firepower Threat Defense Routing
Configure OSPF Areas, Ranges, and Virtual Links

• 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 to 65535. The default value is 1.

Step 7 Click OK to save the area configuration.

Step 8 Select the Range tab, and click Add.
• Choose one of the available networks and whether to advertise, or,

• Click the add icon ( ) to add a new network object. See Network Objects, on page 371 for the procedure
for adding networks.

Step 9 Click OK to save the range configuration.

Step 10 Select the Virtual Link tab, 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 the add icon
( ). See Network Objects, on page 371 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 to 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 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.
• Retransmit Interval—The time in seconds between LSA retransmissions for adjacencies that belong
to the interface. The retransmit interval is the expected round-trip delay between any two routers on the
attached network. The value must be greater than the expected round-trip delay, and can range from 1
to 65535. The default is 5.
When a router sends an LSA to its neighbor, it keeps the LSA until it receives the acknowledgment
message. If the router receives no acknowledgment, it resends the LSA. Be conservative when setting
this value, or needless retransmission can result. The value should be larger for serial lines and virtual
links.
• 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 to 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 the Add button, and enter
the key ID, key, confirm the key, and then click OK.

Firepower Management Center Configuration Guide, Version 6.3

783
 Firepower Threat Defense Routing
Configure OSPF Redistribution

• Password—Provides a clear text password for virtual link authentication, which is not recommended
where security is a concern.
• MD5—Allows MD5 authentication. Click the Add button, and enter the key ID, key, confirm the
key, and then click OK.
Note Ensure to enter only numbers as the MD5 key ID.

Step 11 Click OK to save the virtual link configuration.

Step 12 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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPF.
Step 3 Select the Redistribution tab, and click Add.

You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.

Step 4 Configure the following redistribution options for each OSPF process:
• OSPF Process—Choose 1 or 2.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

784
 Firepower Threat Defense Routing
Configure OSPF Inter-Area Filtering

• RIP—Redistributes routes from the RIP routing process. You can select whether to use subnets
under the Optional list.

• Metric Value—Metric value for the routes being distributed. The default value is 10. Valid values range
from 0 to 16777214.
When redistributing from one OSPF process to another OSPF process on the same device, the metric
will be carried through from one process to the other if no metric value is specified. When redistributing
other processes to an OSPF process, the default metric is 20 when no metric value is specified.
• Metric Type—The metric type is the external link type that is associated with the default route that is
advertised into the OSPF routing domain. The available options are 1 for a Type 1 external route or 2
for a Type 2 external route.
• Tag Value—Tag specifies the 32-bit decimal value attached to each external route that is not used by
OSPF itself, but which may be used to communicate information between ASBRs. If none is specified,
then the remote autonomous system number is used for routes from BGP and EGP. For other protocols,
zero is used. Valid values are from 0 to 4294967295.
• RouteMap—Checks for filtering the importing of routes from the source routing protocol to the current
routing protocol. If this parameter is not specified, all routes are redistributed. If this parameter is specified,
but no route map tags are listed, no routes are imported. Or you can add a new route map by clicking the
add icon ( ). See Route Maps to add a new route map.

Step 5 Click OK to save the redistribution configuration.

Step 6 Click Save on the Routing page to save your changes.

What to do next
Continue with Configure OSPF Inter-Area Filtering, on page 785.

Configure OSPF Inter-Area Filtering

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.

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPF.
Step 3 Select the InterArea tab, and click Add.

Firepower Management Center Configuration Guide, Version 6.3

785
 Firepower Threat Defense Routing
Configure OSPF Filter Rules

You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete inter-areas.

Step 4 Configure the following inter-area filtering options for each OSPF process:
• OSPF Process—Choose 1 or 2.
• 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 5 Click the add icon ( ), 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 6 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 7 Click OK to save the inter-area filtering configuration.

Step 8 Click Save on the Routing page to save your changes.

What to do next
Continue with Configure OSPF Filter Rules, on page 786.

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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPF.
Step 3 Select the Filter Rule tab, and click Add.

Firepower Management Center Configuration Guide, Version 6.3

786
 Firepower Threat Defense Routing
Configure OSPF Summary Addresses

You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete filter rules.

Step 4 Configure the following filter rule options for each OSPF process:
• OSPF Process—Choose 1 or 2.
• Access List—The access list for this OSPF process. To add a new standard access list object, click the
add icon ( ) and see Configure Standard ACL Objects, on page 441.
• 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 5 Click OK to save the filter rule configuration.

Step 6 Click Save on the Routing page to save your changes.

What to do next
Continue with Configure OSPF Summary Addresses, on page 787.

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.
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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPF.
Step 3 Select the Summary Address tab, and click Add.

You can click the edit icon ( ) to edit, or use the right-click menu to cut, copy, past, insert, and delete
summary addresses.

Step 4 Configure the following summary address options for each OSPF process:
• OSPF Process—Choose 1 or 2.

Firepower Management Center Configuration Guide, Version 6.3

787
 Firepower Threat Defense Routing
Configure OSPF Interfaces and Neighbors

• 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 the add icon ( ). See Network Objects, on page 371
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 5 Click OK to save the summary address configuration.

Step 6 Click Save on the Routing page to save your changes.

What to do next
Continue with Configure OSPF Interfaces and Neighbors, on page 788.

Configure OSPF Interfaces and Neighbors

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.
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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPF.
Step 3 Select the Interface tab, and click Add.

You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.

Step 4 Configure the following Interface options for each OSPF process:
• Interface—The interface you are configuring.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

788
Firepower Threat Defense Routing
Configure OSPF Interfaces and Neighbors

• 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 from 1 to 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
from 1 to 65535 seconds. The default is 1 second.
LSAs in the update packet have their ages increased by the amount specified by this field before
transmission. If the delay is not added before transmission over a link, the time in which the LSA
propagates over the link is not considered. The value assigned should take into account the transmission
and propagation delays for the interface. This setting has more significance on very low-speed links.
• Retransmit Interval—Time in seconds between LSA retransmissions for adjacencies that belong to the
interface. The time must be greater than the expected round-trip delay between any two routers on the
attached network. Valid values range from 1 to 65535 seconds. The default is 5 seconds.
When a router sends an LSA to its neighbor, it keeps the LSA until it receives the acknowledgment
message. If the router receives no acknowledgment, it resends the LSA. Be conservative when setting
this value, or needless retransmission can result. The value should be larger for serial lines and virtual
links.
• Dead Interval—Time period in seconds for which hello packets must not be seen before neighbors
indicate that the router is down. The value must be the same for all nodes on the network and can range
from 1 to 65535.
• Hello Multiplier—Specifies the number of Hello packets to be sent per second. Valid values are between
3 and 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 the Add button, and
enter the key ID, key, confirm the key, and then click OK.
• Password—Provides a clear text password for virtual link authentication, which is not recommended
where security is a concern.
• MD5—Allows MD5 authentication. Click the Add button, and enter the key ID, key, confirm the
key, and then click OK.
Note Ensure to enter only numbers as the MD5 key ID.

• Enter Password—The password you configure if you choose Password as the type of authentication.

Firepower Management Center Configuration Guide, Version 6.3

789
 Firepower Threat Defense Routing
Configure OSPF Advanced Properties

• Confirm Password—Confirm the password you chose.

Step 5 Select the Neighbor tab, and click Add.

You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.

Step 6 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 the add icon ( ) 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 7 Click OK to save the neighbor configuration.

Step 8 Click Save on the Routing page to save your changes.

Configure OSPF Advanced Properties

The Advanced Properties tab 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.

Firepower Management Center Configuration Guide, Version 6.3

790
Firepower Threat Defense Routing
Configure OSPF Advanced Properties

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPF, and click Advanced.
Step 3 Select the General tab, and configure the following:
• Router ID—Choose Automatic or IP address for the router ID. If you choose IP address, enter the IP
address in the IP Address field.
• Ignore LSA MOSPF—Suppresses syslog messages when the route receives unsupported LSA Type 6
multicast OSPF (MOSPF) packets.
• RFC 1583 Compatible—Configures RFC 1583 compatibility as the method used to calculate summary
route costs. Routing loops can occur with RFC 1583 compatibility enabled. Disable it to prevent routing
loops. All OSPF routers in an OSPF routing domain should have RFC compatibility set identically.
• Adjacency Changes—Defines the adjacency changes that cause syslog messages to be sent.
By default, a syslog message is generated when an OSPF neighbor goes up or down. You can configure
the router to send a syslog message when an OSPF neighbor goes down and also a syslog for each state.
• Log Adjacency Changes—Causes the Firepower Threat Defense device to send a syslog message
whenever an OSPF neighbor goes up or down. This setting is checked by default.
• Log Adjacency Change Details—Causes the Firepower Threat Defense device to send a syslog
message whenever any state change occurs, not just when a neighbor goes up or down. This setting
is unchecked by default.

• Administrative Route 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.
• 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—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 the add icon ( ) to add a new one. See Route Maps to add a new route map.

Step 4 Click OK to save the general configuration.

Step 5 Select the Non Stop Forwarding tab, and configure Cisco NSF graceful restart for OSPFv2, for an NSF-capable
or NSF-aware device:

Firepower Management Center Configuration Guide, Version 6.3

791
 Firepower Threat Defense Routing
Configure OSPFv3

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 6 Configure IETF NSF Graceful Restart for OSPFv2, for an NSF-capable or NSF-aware device:
a) Check the Enable IETF Non Stop Forwarding Capability check box.
b) In the Length of graceful restart interval (seconds) field, enter the restart interval in seconds. The default
value is 120 seconds. For a restart interval below 30 seconds, graceful restart will be terminated.
c) (Optional) Make sure the Enable IETF nonstop forwarding (NSF) for helper mode check box is
unchecked to disable the IETF NSF helper mode on an NSF-aware device.
d) Enable Strict Link State advertisement checking—When enabled, it indicates that the helper router
will terminate the process of restarting the router if it detects that there is a change to a LSA that would
be flooded to the restarting router, or if there is a changed LSA on the retransmission list of the restarting
router when the graceful restart process is initiated.
e) Enable IETF Non Stop Forwarding—Enables non stop forwarding, which allows for the forwarding
of data packets to continue along known routes while the routing protocol information is being restored
following a switchover. OSPF uses extensions to the OSPF protocol to recover its state from neighboring
OSPF devices. For the recovery to work, the neighbors must support the NSF protocol extensions and be
willing to act as "helpers" to the device that is restarting. The neighbors must also continue forwarding
data traffic to the device that is restarting while protocol state recovery takes place.

Configure OSPFv3
This section describes the tasks involved in configuring an OSPFv3 routing process.

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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPFv3.
Step 3 By default Enable Process 1 is selected. You can enable up to two OSPF process instances.
Step 4 Chose the OSPFv3 role from the drop-down list, and enter a description for it. The options are Internal, ABR,
ASBR, and ABR and ASBR. See About OSPF, on page 777 for descriptions of the OSPFv3 roles.
Step 5 Select the Area tab, and click Add.

Firepower Management Center Configuration Guide, Version 6.3

792
Firepower Threat Defense Routing
Configure OSPFv3 Areas, Route Summaries, and Virtual Links

You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.

Step 6 Select the General tab, and configure the following options for each OSPF process:
• Area ID—The area for which routes are to be summarized.
• Cost—The metric or cost for the summary route, which is used during OSPF SPF calculations to determine
the shortest paths to the destination. Valid values range from 0 to 16777215.
• Type—Specifies Normal, NSSA, or Stub. If you select Normal, there are no other parameters to configure.
If you select Stub, you can choose to send summary LSAs in the area. If you select NSSA, you can
configure the next three options:
• Allow Sending summary LSA into this area—Allows the sending of summary LSAs into the
area.
• Redistribute imports routes to normal and NSSA area—Allows redistribution to import routes
to normal and not to stubby areas.
• Defaults information originate—Generates a default external route into an OSPFv3 routing domain.

• Metric—Metric used for generating the default route. The default value is 10. Valid metric values range
from 0 to 16777214.
• Metric Type—The metric type is the external link type that is associated with the default route that is
advertised into the OSPFv3 routing domain. The available options are 1 for a Type 1 external route or
2 for a Type 2 external route.

Step 7 Click OK to save the general configuration.

Step 8 Select the Route Summary tab, and click Add Route Summary.

You can click the edit icon ( ), 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 the add icon ( ). See
Network Objects, on page 371 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 the Virtual Link tab, 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 the add
icon ( ). See Network Objects, on page 371 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.

Firepower Management Center Configuration Guide, Version 6.3

793
 Firepower Threat Defense Routing
Configure OSPFv3 Redistribution

OSPF sends outgoing packets with an IP header Time to Live (TTL) value of 255 and discards incoming
packets that have TTL values less than a configurable threshold. Because each device that forwards an
IP packet decrements the TTL, packets received via a direct (one-hop) connection have a value of 255.
Packets that cross two hops have a value of 254, and so on. The receive threshold is configured in terms
of the maximum number of hops that a packet may have traveled.
• Dead Interval—The time in seconds that hello packets are not seen before a neighbor indicates that the
router is down. The default is four times the hello interval, or 40 seconds. Valid values range from 1 to
65535.
The dead interval is an unsigned integer. The value must be the same for all routers and access servers
that are attached to a common network.
• Hello Interval—The time in seconds between the hello packets sent on an interface. Valid values range
from 1 to 65535. The default is 10.
The hello interval is an unsigned integer that is to be advertised in the hello packets. The value must be
the same for all routers and access servers on a specific network. The smaller the hello interval, the faster
topological changes are detected, but the more traffic is sent on the interface.
• Retransmit Interval—The time in seconds between LSA retransmissions for adjacencies that belong
to the interface. The retransmit interval is the expected round-trip delay between any two routers on the
attached network. The value must be greater than the expected round-trip delay, and can range from 1
to 65535. The default is 5.
When a router sends an LSA to its neighbor, it keeps the LSA until it receives the acknowledgment
message. If the router receives no acknowledgment, it resends the LSA. Be conservative when setting
this value, or needless retransmission can result. The value should be larger for serial lines and virtual
links.
• Transmit Delay—The estimated time in seconds that is required to send an LSA packet on the interface.
The integer value must be greater than zero. Valid values range from 1 to 8192. The default is 1.
LSAs in the update packet have their own ages incremented by this amount before transmission. If the
delay is not added before transmission over a link, the time in which the LSA propagates over the link
is not considered. The value assigned should take into account the transmission and propagation delays
for the interface. This setting has more significance on very low-speed links.

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

794
Firepower Threat Defense Routing
Configure OSPFv3 Redistribution

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPF.
Step 3 Select the Redistribution tab, and click Add.

You can click the edit icon ( ), or use the right-click menu to cut, copy, past, insert, and delete areas.

Step 4 Configure the following redistribution options for each OSPF process:
• Source Protocol—The source protocol from which routes are being redistributed. The supported protocols
are connected, OSPF, static, and BGP. If you choose OSPF, you must enter the Process ID in the Process
ID field. If you choose BCP, you must add the AS number in the AS Number field.
• Metric —Metric value for the routes being distributed. The default value is 10. Valid values range from
0 to 16777214.
When redistributing from one OSPF process to another OSPF process on the same device, the metric
will be carried through from one process to the other if no metric value is specified. When redistributing
other processes to an OSPF process, the default metric is 20 when no metric value is specified.
• Metric Type—The metric type is the external link type that is associated with the default route that is
advertised into the OSPF routing domain. The available options are 1 for a Type 1 external route or 2
for a Type 2 external route.
• Tag —Tag specifies the 32-bit decimal value attached to each external route that is not used by OSPF
itself, but which may be used to communicate information between ASBRs. If none is specified, then
the remote autonomous system number is used for routes from BGP and EGP. For other protocols, zero
is used. Valid values are from 0 to 4294967295.
• Route Map—Checks for filtering the importing of routes from the source routing protocol to the current
routing protocol. If this parameter is not specified, all routes are redistributed. If this parameter is specified,
but no route map tags are listed, no routes are imported. Or you can add a new route map by clicking the
add icon ( ). See Route Maps, on page 436 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.

Firepower Management Center Configuration Guide, Version 6.3

795
 Firepower Threat Defense Routing
Configure OSPFv3 Summary Prefixes

Step 5 Click OK to save the redistribution configuration.

Step 6 Click Save on the Routing page to save your changes.

What to do next
Continue with Configure OSPFv3 Summary Prefixes, on page 796.

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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPFv3.
Step 3 Select the Summary Prefix tab, and click Add.

You can click the edit icon ( ), 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 the add
icon ( ) to add a new network object. See Network Objects, on page 371 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.

Step 6 Click Save on the Routing page to save your changes.

What to do next
Continue with Configure OSPFv3 Interfaces, Authentication, and Neighbors, on page 796.

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.

Firepower Management Center Configuration Guide, Version 6.3

796
Firepower Threat Defense Routing
Configure OSPFv3 Interfaces, Authentication, and Neighbors

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPFv3.
Step 3 Select the Interface tab, and click Add.
You can click the Pencil icon to edit, or use the right-click menu to cut, copy, past, insert, and delete areas.

Step 4 Configure the following interface options for each OSPFv3 process:
• Interface—The interface you are configuring.
• Enable OSPFv3—Enables OSPFv3.
• OSPF Process—Choose 1 or 2.
• Area—The area ID for this process.
• Instance —Specifies the area instance ID to be assigned to the interface. An interface can have only one
OSPFv3 area. You can use the same area on multiple interfaces, and each interface can use a different
area instance ID.

Step 5 Select the Properties tab, 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

Firepower Management Center Configuration Guide, Version 6.3

797
 Firepower Threat Defense Routing
Configure OSPFv3 Interfaces, Authentication, and Neighbors

interface. Specifying an interface as point-to-point, nonbroadcast lets you transmit OSPF routes over
VPN tunnels.
• Cost—Specifies the cost of sending a packet on the interface. Valid values for this setting range from 0
to 255. The default value is 1. Entering 0 for this setting makes the router ineligible to become the
designated router or backup designated router. This setting does not apply to interfaces that are configured
as point-to-point, nonbroadcast interfaces.
When two routers connect to a network, both attempt to become the designated router. The device with
the higher router priority becomes the designated router. If there is a tie, the router with the higher router
ID becomes the designated router.
• Priority—Determines the designated router for a network. Valid values range from 0 to 255.
• Dead Interval—Time period in seconds for which hello packets must not be seen before neighbors
indicate that the router is down. The value must be the same for all nodes on the network and can range
from 1 to 65535.
• Poll Interval— Time period in seconds between OSPF packets that the router will send before adjacency
is established with a neighbor. Once the routing device detects an active neighbor, the hello packet interval
changes from the time specified in the poll interval to the time specified in the hello interval. Valid values
range from 1 to 65535 seconds.
• Retransmit Interval—Time in seconds between LSA retransmissions for adjacencies that belong to the
interface. The time must be greater than the expected round-trip delay between any two routers on the
attached network. Valid values range from 1 to 65535 seconds. The default is 5 seconds.
• Transmit Delay—Estimated time in seconds to send a link-state update packet on the interface. Valid
values range from 1 to 65535 seconds. The default is 1 second.

Step 6 Click OK to save the properties configuration.

Step 7 Select the Authentication tab, 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.

Firepower Management Center Configuration Guide, Version 6.3

798
 Firepower Threat Defense Routing
Configure OSPFv3 Advanced Properties

Step 9 Select the Neighbor tab, 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.

Step 11 Click OK to save the Interface configuration.

Configure OSPFv3 Advanced Properties

The Advanced Properties tab 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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select Routing > OSPFv3, and click 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.

Firepower Management Center Configuration Guide, Version 6.3

799
 Firepower Threat Defense Routing
Configure OSPFv3 Advanced Properties

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 the General tab, and configure the following:
• Adjacency Changes—Defines the adjacency changes that cause syslog messages to be sent.
By default, a syslog message is generated when an OSPF neighbor goes up or down. You can configure
the router to send a syslog message when an OSPF neighbor goes down and also a syslog for each state.
• Adjacency Changes—Causes the Firepower Threat Defense device to send a syslog message
whenever an OSPF neighbor goes up or down. This setting is checked by default.
• Include Details—Causes the Firepower Threat Defense device to send a syslog message whenever
any state change occurs, not just when a neighbor goes up or down. This setting is unchecked by
default.

• Administrative Route Distances—Allows you to modify the settings that were used to configure
administrative route distances for inter-area, intra-area, and external IPv6 routes. The administrative
route distance is an integer from 1 to 254. The default is 110.
• Default Information Originate—Check the Enable check box to generate a default external route into
an OSPFv3 routing domain and configure the following options:
• Always Advertise—Will always advertise the default route whether or not one exists.
• Metric—Metric used for generating the default route. Valid metric values range from 0 to 16777214.
The default value is 10.
• Metric Type—The external link type that is associated with the default route that is advertised into
the OSPFv3 routing domain. Valid values are 1 (Type 1 external route) and 2 (Type 2 external
route). The default is Type 2 external route.
• Route Map—Choose the routing process that generates the default route if the route map is satisfied
or click the add icon ( ) to add a new one. See Route Maps, on page 436 to add a new route map.

Step 6 Click OK to save the general configuration.

Step 7 Select the Passive Interface tab, 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 the Timer tab, 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.

Firepower Management Center Configuration Guide, Version 6.3

800
Firepower Threat Defense Routing
Configure OSPFv3 Advanced Properties

• 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.
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 the Non Stop Forwarding tab, 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.
Step 15 Click Save on the Routing page to save your changes.

Firepower Management Center Configuration Guide, Version 6.3

801
 Firepower Threat Defense Routing
Configure OSPFv3 Advanced Properties

Firepower Management Center Configuration Guide, Version 6.3

802
 CHAPTER 39
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 803
• Guidelines for BGP, on page 806
• Configure BGP, on page 806

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.
Routes learned via BGP have properties that are used to determine the best route to a destination, when multiple
paths exist to a particular destination. These properties are referred to as BGP attributes and are used in the
route selection process:
• Weight—This is a Cisco-defined attribute that is local to a router. The weight attribute is not advertised
to neighboring routers. If the router learns about more than one route to the same destination, the route
with the highest weight is preferred.
• Local preference—The local preference attribute is used to select an exit point from the local AS. Unlike
the weight attribute, the local preference attribute is propagated throughout the local AS. If there are
multiple exit points from the AS, the exit point with the highest local preference attribute is used as an
exit point for a specific route.
• Multi-exit discriminator—The multi-exit discriminator (MED) or metric attribute is used as a suggestion
to an external AS regarding the preferred route into the AS that is advertising the metric. It is referred
to as a suggestion because the external AS that is receiving the MEDs may also be using other BGP
attributes for route selection. The route with the lower MED metric is preferred.

Firepower Management Center Configuration Guide, Version 6.3

803
 Firepower Threat Defense Routing
When to Use BGP

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

Firepower Management Center Configuration Guide, Version 6.3

804
 Firepower Threat Defense Routing
BGP Multipath

• 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 805.
• 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)

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).

Firepower Management Center Configuration Guide, Version 6.3

805
 Firepower Threat Defense Routing
Guidelines for BGP

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

Guidelines for BGP

Firewall Mode Guidelines
Does not support transparent firewall mode. BGP is supported only in router mode.

IPv6 Guidelines
Supports IPv6. Graceful restart is not supported for IPv6 address family.

Configure BGP
To configure BGP, see the following topics:

Procedure

Step 1 Configure BGP Basic Settings, on page 807

Step 2 Configure BGP General Settings, on page 809
Step 3 Configure BGP Neighbor Settings, on page 810
Step 4 Configure BGP Aggregate Address Settings, on page 813
Step 5 Configure BGPv4 Filtering Settings, on page 814
Note The Filtering section is applicable only to IPv4 settings

Step 6 Configure BGP Network Settings, on page 815

Step 7 Configure BGP Redistribution Settings, on page 815
Step 8 Configure BGP Route Injection Settings, on page 816

Firepower Management Center Configuration Guide, Version 6.3

806
 Firepower Threat Defense Routing
Configure BGP Basic Settings

Configure BGP Basic Settings

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

You can set many basic settings for BGP.

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select the Routing tab.
Step 3 Select BGP.
Step 4 Select the Enable BGP checkbox 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 the Edit (pencil) button 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.
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:

Firepower Management Center Configuration Guide, Version 6.3

807
 Firepower Threat Defense Routing
Configure BGP Basic Settings

a) Enter a value for Default Local Preference between 0 and 4294967295.The default value is 100. Higher
values indicate higher preference. This preference is sent to all routers and access servers in the local
autonomous system.
b) Check the Allow comparing MED from different neighbors check box to allow the comparison of
Multi Exit Discriminator (MED) for paths from neighbors in different autonomous systems. This is
disabled by default.
c) Check the Compare Router ID for identical EBGP paths check box to compare similar paths received
from external BGP peers during the best path selection process and switch the best path to the route with
the lowest router ID. This is disabled by default.
d) Check the Pick the best MED path among paths advertised from the neighboring AS check box to
enable MED comparison among paths learned from confederation peers. The comparison between MEDs
is made only if no external autonomous systems are there in the path. This is disabled by default.
e) Check the Treat missing MED as the least preferred one check box to consider the missing MED
attribute as having a value of infinity, making the path the least desirable; therefore, a path with a missing
MED is least preferred. This is disabled by default.
f) Click OK.
Step 8 (Optional) Edit the Neighbor Timers section:
a) Enter the time interval for which the BGP neighbor remains active after not sending a keepalive message
in the Keepalive interval field. At the end of this keepalive interval, the BGP peer is declared dead, if
no messages are sent. The default value is 60 seconds.
b) Enter the time interval for which the BGP neighbor remains active while a BGP connection is being
initiated and configured in the Hold time field. The default value is 180 seconds.
c) (Optional) Enter the minimum time interval for which the BGP neighbor remains active while a BGP
connection is being initiated and configured in the Min Hold time field. Specify a value from 0 to 65535.
d) Click OK.
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.

Firepower Management Center Configuration Guide, Version 6.3

808
 Firepower Threat Defense Routing
Configure BGP General Settings

Configure BGP General Settings

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Procedure

Step 1 Choose Routing > BGP > IPv4or IPv6 and select the General tab.
Step 2 In the General tab, 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 clickOK :
• (Optional) Generate Default Routes— Select this to configure, a BGP routing process to distribute
a default route (network 0.0.0.0).
• (Optional) Summarize subnet routes into network-level routes— Select this to configure automatic
summarization of subnet routes into network-level routes. This checkbox is applicable only to IPv4
settings.
• (Optional) Advertise inactive routes— Select this to advertise routes that are not installed in the
routing information base (RIB).
• (Optional) Synchronise between BGP and IGP system— Select this to enable synchronization
between BGP and your Interior Gateway Protocol (IGP) system. Usually, a BGP speaker does not
advertise a route to an external neighbor unless that route is local or exists in the IGP. This feature
allows routers and access servers within an autonomous system to have the route before BGP makes
it available to other autonomous systems.
• (Optional) Redistribute IBGP into IGP— Select this to configure iBGP redistribution into an
interior gateway protocol (IGP), such as OSPF.

c) In the Administrative Route Distances section, update the following as required, and clickOK :
• External — Enter the administrative distance for external BGP routes. Routes are external when
learned from an external autonomous system. The range of values for this argument are from 1 to
255. The default value is 20.
• Internal — Enter administrative distance for internal BGP routes. Routes are internal when learned
from peer in the local autonomous system. The range of values for this argument are from 1 to 255.
The default value is 200.

Firepower Management Center Configuration Guide, Version 6.3

809
 Firepower Threat Defense Routing
Configure BGP Neighbor Settings

• Local — Enter administrative distance for local BGP routes. Local routes are those networks listed
with a network router show command, often as back doors, for the router or for the networks that is
being redistributed from another process. The range of values for this argument are from 1 to 255.
The default value is 200.

d) In the Next Hop section, optionally select the Enable address tracking checkbox to enable BGP next
hop address tracking and enter the Delay Interval between checks on updated next-hop routes installed
in the routing table. Click OK.
Note The Next Hop section is applicable only to IPv4 settings.

e) In the Forward Packets over Multiple Paths section, update the following as required and click OK:
• (Optional) Number of Paths — Specify the maximum number of Border Gateway Protocol routes
that can be installed in a routing table. The range of values are from 1 to 8. The default value is 1.
• (Optional) IBGP Number of Paths — Specify the maximum number of parallel internal Border
Gateway Protocol (iBGP) routes that can be installed in a routing table. The range of values are from
1 to 8. The default value is 1.

Step 3 Click Save.

Configure BGP Neighbor Settings

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

A BGP router needs to establish a connection with each of its peers before exchanging updates. These peers
are called BGP neighbors. Use the Neighbor tab to define BGP IPv4 or IPv6 neighbors and neighbor settings.

Procedure

Step 1 Choose Routing > BGP > IPv4or IPv6 and click the Neighbor tab.
Step 2 Click Add to define BGP neighbors and neighbor settings.
Step 3 Enter the BGP neighbor IP address. This IP address is added to the BGP neighbor table.
Step 4 Enter the BGP neighbor Interface.
Note The Interface field is only applicable to IPv6 settings.

Step 5 Enter the autonomous system to which the BGP neighbor belongs, in the Remote AS field.
Step 6 Select the Enabled address checkbox to enable communication with this BGP neighbor. Further neighbor
settings will be configured only if the Enabled address check box is selected.
Step 7 (Optional) Select the Shutdown administratively checkbox to disable a neighbor or peer group.

Firepower Management Center Configuration Guide, Version 6.3

810
Firepower Threat Defense Routing
Configure BGP Neighbor Settings

Step 8 (Optional) Select the Configure graceful restart checkbox 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 9 (Optional) Enter a Description for the BGP neighbor.

Step 10 (Optional) In the Filtering Routes tab, 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 the Terminate peering when prefix limit is exceeded radio button 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 radio button to generate a log
message when the maximum prefix limit is exceeded. Here, the BGP neighbor will not be terminated.

g) Click OK.
Step 11 (Optional) In the Routes tab, 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 the Add Row + button. 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.

Firepower Management Center Configuration Guide, Version 6.3

811
 Firepower Threat Defense Routing
Configure BGP Neighbor Settings

2. Select the Exist Map radio button and choose a route map from the Route Map Object Selector. This
route map will be compared with the routes in the BGP table, to determine whether or not the advertise
map route is advertised.
3. Select the Non-Exist Map radio button and choose a route map from the Route Map Object Selector.
This route map will be compared with the routes in the BGP table, to determine whether or not the
advertise map route is advertised.
4. Click OK.

Step 12 In the Timers tab, 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 13 In the Advanced tab, 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 first character cannot be a number. 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 the Allow connections with neighbor that is not directly connected radio button 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 the
Limited number of TTL hops to neighbor radio button, 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.

Firepower Management Center Configuration Guide, Version 6.3

812
 Firepower Threat Defense Routing
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 14 Update the Migration tab, 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 15 Click OK.
Step 16 Click Save.

Configure BGP Aggregate Address Settings

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

813
 Firepower Threat Defense Routing
Configure BGPv4 Filtering Settings

Procedure

Step 1 When editing a Firepower Threat Defense device, select Routing > BGP > IPv4or IPv6 and select the
Aggregate Address tab.
Step 2 Click the Aggregate Addresses tab.
Step 3 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 4 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 814
• For BGPv6 settings, proceed to Configure BGP Network Settings, on page 815

Configure BGPv4 Filtering Settings

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 1 Choose Routing > BGP > IPv4 and select the Filtering tab.
Step 2 Click Add and update the Add Filter dialog:

Firepower Management Center Configuration Guide, Version 6.3

814
 Firepower Threat Defense Routing
Configure BGP Network Settings

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.
e) Click OK.
Step 3 Click Save.

Configure BGP Network Settings

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 1 Choose Routing > BGP > IPv4or IPv6 and select the Networks tab.
Step 2 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 3 Click Save.

Configure BGP Redistribution Settings

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

Redistribution settings allow you to define the conditions for redistributing routes from another routing domain
into BGP.

Firepower Management Center Configuration Guide, Version 6.3

815
 Firepower Threat Defense Routing
Configure BGP Route Injection Settings

Procedure

Step 1 Choose Routing > BGP > IPv4or IPv6 and select the Redistribution tab.
Step 2 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.
b) Process ID— Enter the identifier for the selected source protocol. Applies to the OSPF protocol.
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.

Configure BGP Route Injection Settings

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

Route Injection settings allow you to define the routes to be conditionally injected into the BGP routing table.

Procedure

Step 1 Choose Routing > BGP > IPv4or IPv6 and select the Route Injection tab.
Step 2 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.
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.

Firepower Management Center Configuration Guide, Version 6.3

816
Firepower Threat Defense Routing
Configure BGP Route Injection Settings

Step 3 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

817
 Firepower Threat Defense Routing
Configure BGP Route Injection Settings

Firepower Management Center Configuration Guide, Version 6.3

818
 CHAPTER 40
RIP for Firepower Threat Defense
This chapter describes how to configure the FTD to route data, perform authentication, and redistribute routing
information, using the Routing Information Protocol (RIP).
• About RIP, on page 819
• Guidelines for RIP, on page 820
• Configure RIP, on page 821

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
routers maintain only the best route (the route with the lowest metric value) to a destination. After updating

Firepower Management Center Configuration Guide, Version 6.3

819
 Firepower Threat Defense Routing
RIP Routing Metric

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. These include a routing-update timer, a route-timeout
timer, and a route-flush timer. The routing-update timer clocks the interval between periodic routing updates.
Generally, it is set to 30 seconds, with a small random amount of time added whenever the timer is reset. This
is done to help prevent congestion, which could result from all routers simultaneously attempting to update
their neighbors. Each routing table entry has a route-timeout timer associated with it. When the route-timeout
timer expires, the route is marked invalid but is retained in the table until the route-flush timer expires.

Guidelines for RIP

IPv6 Guidelines
Does not support IPv6.

Additional Guidelines
The following information applies to RIP Version 2 only:
• If using neighbor authentication, the authentication key and key ID must be the same on all neighbor
devices that provide RIP Version 2 updates to the interface.
• With RIP Version 2, the Firepower Threat Defense device transmits and receives default route updates
using the multicast address 224.0.0.9. In passive mode, it receives route updates at that address.

Firepower Management Center Configuration Guide, Version 6.3

820
 Firepower Threat Defense Routing
Configure RIP

• When RIP Version 2 is configured on an interface, the multicast address 224.0.0.9 is registered on that
interface. When a RIP Version 2 configuration is removed from an interface, that multicast address is
unregistered.

Limitations
• The Firepower Threat Defense device cannot pass RIP updates between interfaces.
• RIP Version 1 does not support variable-length subnet masks.
• RIP has a maximum hop count of 15. A route with a hop count greater than 15 is considered unreachable.
• RIP convergence is relatively slow compared to other routing protocols.
• You can only enable a single RIP process on the Firepower Threat Defense device.

Configure RIP
RIP is a distance-vector routing protocol that uses hop count as the metric for path selection.

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Select the Routing tab.
Step 3 Select RIP from the table of contents.
Step 4 Select the Enable RIP checkbox 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 checkbox 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 the Networks tab. 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.

Firepower Management Center Configuration Guide, Version 6.3

821
 Firepower Threat Defense Routing
Configure RIP

Step 9 (Optional) Click the Passive Interface tab. 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 the Redistribution tab to manage redistribution routes. These are the routes that are being redistributed
from other routing processes into the RIP routing process.
a) Click Add to specify redistribution routes.
b) Select the routing protocol to redistribute into the RIP routing process, in the Protocol drop-down list.
Note For the OSPF protocol, specify a process ID. Similarly, specify an AS path for BGP. When you
choose the Connected option in the Protocol drop-down list, you can redistribute, directly
connected networks into the RIP routing process.

c) (Optional) If you are redistributing OSPF routes into the RIP routing process, you can select specific types
of OSPF routes to redistribute in the Match drop-down list . Ctrl-click to select multiple types:
• Internal – Routes internal to the autonomous system (AS) are redistributed.
• External 1 – Type 1 routes external to the AS are redistributed.
• External 2 – Type 2 routes external to the AS are redistributed.
• NSSA External 1 – Type 1 routes external to a not-so-stubby area (NSSA) are redistributed.
• NSSA External 2 – Type 2 routes external to an NSSA are redistributed

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 the Filtering tab 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 the appropriate radio button 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:

Firepower Management Center Configuration Guide, Version 6.3

822
Firepower Threat Defense Routing
Configure RIP

• 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 the Broadcast tab to add or edit interface configurations. Using the Broadcast tab, you can
override the global RIP versions to send or receive per interface. You can also define the authentication
parameters per interface if you want to implement authentication to ensure valid RIP updates.
a) Click Add to add interface configurations.
b) Enter or Select an interface defined on this appliance in the Interface field.
c) In the Send option, select the appropriate boxes to specify sending updates using the RIP Version 1,
Version 2, or both. These options let you override, for the specified interface, the global Send versions
specified .
d) In the Receive option, select the appropriate boxes to specify accepting updates using the RIP Version
1, Version 2, or both. These options let you override, for the specified interface, the global Receive
versions specified .
e) Select the Authentication used on this interface for RIP broadcasts.
• None – No authentication
• MD5 – Employ MD5
• Clear Text – Employ clear-text authentication

If you choose MD5 or Clear Text, you must also provide the following authentication parameters.
• Key ID – The ID of the authentication key. Valid values are from 0 to 255.
• Key – The key used by the chosen authentication method. Can contain up to 16 characters
• Confirm – Enter the authentication key again, to confirm

f) Click OK.

Firepower Management Center Configuration Guide, Version 6.3

823
 Firepower Threat Defense Routing
Configure RIP

Firepower Management Center Configuration Guide, Version 6.3

824
 CHAPTER 41
Multicast Routing for Firepower Threat Defense
This chapter describes how to configure the Firepower Threat Defense device to use the multicast routing
protocol.
• About Multicast Routing, on page 825
• Guidelines for Multicast Routing, on page 829
• Configure IGMP Features, on page 829
• Configure PIM Features, on page 834
• Configure Multicast Routes, on page 840
• Configure Multicast Boundary Filters, on page 841

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.

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

Firepower Management Center Configuration Guide, Version 6.3

825
 Firepower Threat Defense Routing
Stub Multicast Routing

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

826
 Firepower Threat Defense Routing
PIM Source Specific Multicast Support

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
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.

Firepower Management Center Configuration Guide, Version 6.3

827
 Firepower Threat Defense Routing
PIM Bootstrap Router (BSR)

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.

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

Firepower Management Center Configuration Guide, Version 6.3

828
 Firepower Threat Defense Routing
Multicast Group Concept

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 primary unit sends all multicast
routing packets and data packets until fast-path forwarding is established. After fast-path forwarding is
established, subordinate 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 primary unit is common.

Guidelines for Multicast Routing

Context Mode
Supported in single context mode.

Firewall Mode
Supported only in routed firewall mode. Transparent firewall mode is not supported.

IPv6
Does not support IPv6.

Clustering
In clustering, for IGMP and PIM, this feature is only supported on the primary unit.

Additional Guidelines
You must configure an access control or prefilter rule on the inbound security zone to allow traffic to the
multicast host, such as 224.1.2.3. However, you cannot specify a destination security zone for the rule, or it
cannot be applied to multicast connections during initial connection validation.

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

Firepower Management Center Configuration Guide, Version 6.3

829
 Firepower Threat Defense Routing
Enable Multicast Routing

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 830

Step 2 Configure IGMP Protocol, on page 831.
Step 3 Configure IGMP Access Groups, on page 832.
Step 4 Configure IGMP Static Groups, on page 833.
Step 5 Configure IGMP Join Groups, on page 833.

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 table lists the maximum number of entries for specific multicast tables based on the amount
of RAM on the Firepower Threat Defense device. Once these limits are reached, any new entries are discarded.

Table 69: Entry Limits for Multicast Tables

Table 16 MB 128 MB 128+ MB

MFIB 1000 3000 30000

IGMP Groups 1000 3000 30000

PIM Routes 3000 7000 72000

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > IGMP.
Step 3 Check the Enable Multicast Routing check box.
Checking this check box enables IP multicast routing on the Firepower Threat Defense device. Unchecking
this check box disables IP multicast routing. By default, multicast is disabled. Enabling multicast routing
enables multicast on all interfaces.

Firepower Management Center Configuration Guide, Version 6.3

830
 Firepower Threat Defense Routing
Configure IGMP Protocol

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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > IGMP.
Step 3 On the Protocol tab, 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.

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.

Firepower Management Center Configuration Guide, Version 6.3

831
 Firepower Threat Defense Routing
Configure IGMP Access Groups

• Response Time—The interval in seconds before the Firepower Threat Defense device deletes the group.
The range is 1 to 25. The default is 10.
If the Firepower Threat Defense device does not receive a response to a host query within this amount
of time, it deletes the group.
• Group Limit—The maximum number of hosts that can join on an interface. The range is 1 to 500. The
default is 500.
You can limit the number of IGMP states resulting from IGMP membership reports on a per-interface
basis. Membership reports exceeding the configured limits are not entered in the IGMP cache, and traffic
for the excess membership reports is not forwarded
• Query Timeout—The period of time in seconds before which the Firepower Threat Defense device
takes over as the requester for the interface after the previous requester has stopped. The range is 60 to
300. The default is 255.

Step 5 Click OK to save the IGMP protocol configuration.

Configure IGMP Access Groups

You can control access to multicast groups by using access control lists.

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > Access Group.
Step 3 On the Access Group tab, 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.

Step 4 Configure the following options:

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 radio buttons:
• Standard Access List— From the Standard Access List drop-down list, select the standard ACL
or click the add icon ( ) to create a new standard ACL. See Configure Standard ACL Objects, on
page 441 for the procedure.
• Extended Access List—From the Extended Access List drop-down list, select the extended ACL
or click the add icon ( ) to create a new extended ACL. See Configure Extended ACL Objects, on
page 439 for the procedure.

Step 5 Click OK to save the access group configuration.

Firepower Management Center Configuration Guide, Version 6.3

832
 Firepower Threat Defense Routing
Configure IGMP Static Groups

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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > IGMP.
Step 3 On the Static Group tab, 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.

Step 4 Configure the following options:

• 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 the add icon ( ) 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 833 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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > IGMP.
Step 3 On the Join Group tab, click Add or Edit.

Firepower Management Center Configuration Guide, Version 6.3

833
 Firepower Threat Defense Routing
Configure PIM Features

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.

Step 4 Configure the following options:

• 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 the Plus icon 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.

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 834

Step 2 Configure PIM Neighbor Filters, on page 835
Step 3 Configure PIM Bidirectional Neighbor Filters, on page 836
Step 4 Configure PIM Rendezvous Points, on page 837
Step 5 Configure PIM Route Trees, on page 838
Step 6 Configure PIM Request Filters, on page 838
Step 7 Configure Multicast Boundary Filters, on page 841

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.

Firepower Management Center Configuration Guide, Version 6.3

834
 Firepower Threat Defense Routing
Configure PIM Neighbor Filters

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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On the Protocol tab, click Add or Edit.
Use the Add PIM parameters dialog box to add new PIM parameters to the interface. Use the Edit PIM
parameters dialog box to change existing parameters.

Step 4 Configure the following options:

• 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.
• 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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On the Neighbor Filter tab, 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.

Firepower Management Center Configuration Guide, Version 6.3

835
 Firepower Threat Defense Routing
Configure PIM Bidirectional Neighbor Filters

Step 4 Configure the following options:

• 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
the add icon ( ) to create a new standard ACL. See Configure Standard ACL Objects, on page 441 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.

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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Multicast Routing > PIM.
Step 3 On the Bidirectional Neighbor Filter tab, 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.

Step 4 Configure the following options:

• From the Interface drop-down list, select the interface to which you want to configure the PIM
bidirectional neighbor filter ACL entry.

Firepower Management Center Configuration Guide, Version 6.3

836
 Firepower Threat Defense Routing
Configure PIM Rendezvous Points

• Standard Access List— From the Standard Access List drop-down list, select a standard ACL or click
the add icon ( ) to create a new standard ACL. See Configure Standard ACL Objects, on page 441 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 827 for more information about bidirectional PIM.
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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On the Rendezvous Points tab, 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.

Step 4 Configure the following options:

• From the Rendezvous Point IP address drop-down list, select the IP address that you want to add as
an RP or click the add icon ( ) 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 the Use this RP for all Multicast Groups radio button 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

Firepower Management Center Configuration Guide, Version 6.3

837
 Firepower Threat Defense Routing
Configure PIM Route Trees

ACL or click the add icon ( ) to create a new standard ACL. See Configure Standard ACL Objects,
on page 441 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.

Note This behavior is known as Shortest Path Switchover (SPT). We recommend that you always use the Shared
Tree option.

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On the Route Tree tab, select the path for the route tree:
• Click the Shortest Path radio button to use the shortest-path tree for all multicast groups.
• Click the Shared Tree radio button to use the shared tree for all multicast groups.
• Click the Shared tree for below mentioned group radio button 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 the add icon ( ) to create a new standard ACL. See Configure Standard ACL Objects, on page
441 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.

Firepower Management Center Configuration Guide, Version 6.3

838
 Firepower Threat Defense Routing
Configure the Firepower Threat Defense Device as a Candidate Bootstrap Router

Procedure

Step 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On the Request Filter tab, 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 the add icon ( )
to create a new extended ACL. See Configure Extended ACL Objects, on page 439 for the procedure.
Note In the Add Extended Access List Entry dialog box, select Allow from the drop-down list o
create a rule that allows the specified source of the specified multicast traffic to register with
the Firepower Threat Defense device, or select Block to create a rule that prevents the specified
source of the specified multicast traffic from registering with the Firepower Threat Defense
device.

• If you choose Route Map, select a route map from the Route Map drop-down list, or click the add icon
( ) 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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > PIM.
Step 3 On the Bootstrap Router tab, check the Configure this FTD as a Candidate Bootstrap Router (C-BSR)
check box to perform the C-BSR setup.
a) From the Interface drop-down list, select the interface on the Firepower Threat Defense device from
which the BSR address is derived to make it a candidate.
This interface must be enabled with PIM.
b) In the Hash mask length field, enter the length of a mask (32 bits maximum) that is to be ANDed with
the group address before the hash function is called. All groups with the same seed hash (correspond) to
the same RP. For example, if this value is 24, only the first 24 bits of the group addresses matter. This
fact allows you to get one RP for multiple groups. The range is 0 to 32.
c) In the Priority field, enter the priority of the candidate BSR. The BSR with the larger priority is preferred.
If the priority values are the same, the router with the larger IP address is the BSR. The range is 0 to 255.
The default value is 0.

Firepower Management Center Configuration Guide, Version 6.3

839
 Firepower Threat Defense Routing
Configure Multicast Routes

Step 4 (Optional) Click the add icon ( ) 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.

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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > Multicast Routes, and then click 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 the add icon ( ) to add a new
one. See Creating Network Objects for the procedure.
Step 4 To configure an interface to forward the route, click the Interface radio button 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 the Address radio button and configure the following
options:
• In the RPF Address field, enter the IP address for the multicast route.

Firepower Management Center Configuration Guide, Version 6.3

840
 Firepower Threat Defense Routing
Configure Multicast Boundary Filters

• 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
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 1 Choose Devices > Device Management, and edit the FTD device.
Step 2 Choose Routing > Multicast Routing > Multicast Boundary Filter, and then click Add or Edit.
Use the Add Multicast Boundary Filter dialog box to add new multicast boundary filters to the Firepower
Threat Defense device. Use the Edit Multicast Boundary Filter dialog box to change existing parameters.
You can configure a multicast boundary for administratively scoped multicast addresses. A multicast boundary
restricts multicast data packet flows and enables reuse of the same multicast group address in different
administrative domains. When a multicast boundary is defined on an interface, only the multicast traffic
permitted by the filter ACL passes through the interface.

Step 3 From the Interface drop-down list, choose the interface for which you are configuring the multicast boundary
filter ACL.
Step 4 From the Standard Access List drop-down list, choose the standard ACL you want to use, or click the add
icon ( ) to create a new standard ACL. See Configure Standard ACL Objects, on page 441 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.

Firepower Management Center Configuration Guide, Version 6.3

841
 Firepower Threat Defense Routing
Configure Multicast Boundary Filters

Firepower Management Center Configuration Guide, Version 6.3

842
PA R T XII
Firepower Threat Defense VPN
• VPN Overview for Firepower Threat Defense, on page 845
• Site-to-Site VPNs for Firepower Threat Defense, on page 857
• Remote Access VPNs for Firepower Threat Defense, on page 869
• VPN Monitoring for Firepower Threat Defense, on page 919
• VPN Troubleshooting for Firepower Threat Defense, on page 923
 CHAPTER 42
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 only. 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.
Site-to-site VPNs on 7000 and 8000 Series devices, referred to as Gateway VPNs or Firepower VPNs in the
Firepower Management Center are described in Gateway VPNs, on page 1329.
• VPN Types, on page 845
• VPN Basics, on page 846
• VPN Packet Flow, on page 848
• VPN Licensing, on page 848
• How Secure Should a VPN Connection Be?, on page 848
• VPN Topology Options, on page 853

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.

Firepower Management Center Configuration Guide, Version 6.3

845
 Firepower Threat Defense VPN
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.
• Site-to-site VPNs on 7000 and 8000 Series devices.
These site-to-site VPNs are referred to as Gateway VPNs or Firepower VPNs in the Firepower
Management Center. See Gateway VPNs, on page 1329, for information on this type of VPN connection.

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)

Internet Key Exchange (IKE) is a key management protocol that is used to authenticate IPsec peers, negotiate
and distribute IPsec encryption keys, and to automatically establish IPsec security associations (SAs).

Firepower Management Center Configuration Guide, Version 6.3

846
 Firepower Threat Defense VPN
IPsec

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

Firepower Management Center Configuration Guide, Version 6.3

847
 Firepower Threat Defense VPN
VPN Packet Flow

IKEv1 and IKEv2. In IKEv1 proposals (or transform sets), for each parameter, you set one value. For
IKEv2 proposals, you can configure multiple encryption and integration algorithms for a single proposal.
• A crypto map, combines all components required to set up IPsec security associations (SA), including
IPsec rules, proposals, remote peers, and other parameters that are necessary to define an IPsec SA. When
two peers try to establish an SA, they must each have at least one compatible crypto map entry.
Dynamic crypto map policies are used in site-to-site VPNs when an unknown remote peer tries to start
an IPsec security association with the local hub. The hub cannot be the initiator of the security association
negotiation. Dynamic crypto-policies allow remote peers to exchange IPsec traffic with a local hub even
if the hub does not know the remote peer’s identity. A dynamic crypto map policy essentially creates a
crypto map entry without all the parameters configured. The missing parameters are later dynamically
configured (as the result of an IPsec negotiation) to match a remote peer’s requirements.
Dynamic crypto map policies apply only in a hub-and-spoke and full-mesh VPN topologies. In a
point-to-point or full mesh VPN topology, you can apply only static crypto map policies. Emulate the
use of dynamic crypto-maps in a point-to-point topology by creating a hub-and-spoke topology with two
devices. Specify a dynamic IP address for the spoke and enable dynamic crypto-maps on this topology.

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.

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

Firepower Management Center Configuration Guide, Version 6.3

848
 Firepower Threat Defense VPN
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 1135 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.
• 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-GMAC—(IKEv2 IPsec proposals only.) Advanced Encryption Standard Galois Message
Authentication Code is a block cipher mode of operation providing only data-origin authentication. It is
a variant of AES-GCM that allows data authentication without encrypting the data. AES-GMAC offers
three different key strengths: 128-, 192-, and 256-bit keys.
• 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.
• 3DES—Triple DES, which encrypts three times using 56-bit keys, is more secure than DES because it
processes each block of data three times with a different key. However, it uses more system resources
and is slower than DES.
• DES—Data Encryption Standard, which encrypts using 56-bit keys, is a symmetric secret-key block
algorithm. It is faster than 3DES and uses less system resources, but it is also less secure. If you do not
need strong data confidentiality, and if system resources or speed is a concern, choose DES.

Firepower Management Center Configuration Guide, Version 6.3

849
 Firepower Threat Defense VPN
Deciding Which Hash Algorithms to Use

• Null—A null encryption algorithm provides authentication without encryption. This is typically used
for testing purposes only.

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)—Produces a 160-bit digest. SHA is more resistant to brute-force attacks
than MD5. However, it is also more resource intensive than MD5. For implementations that require the
highest level of security, use the SHA hash algorithm.
Standard SHA (SHA1) produces a 160-bit digest.
The following SHA-2 options, which are even more secure, are available for IKEv2 configurations.
Choose one of these if you want to implement the NSA Suite B cryptography specification.
• SHA256—Specifies the Secure Hash Algorithm SHA 2 with the 256-bit digest.
• SHA384—Specifies the Secure Hash Algorithm SHA 2 with the 384-bit digest.
• SHA512—Specifies the Secure Hash Algorithm SHA 2 with the 512-bit digest.

• MD5 (Message Digest 5)—Produces a 128-bit digest. MD5 uses less processing time for an overall faster
performance than SHA, but it is considered to be weaker than SHA.
• 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/GMAC 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 allow groups 1, 2, and 5 only.
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.

Firepower Management Center Configuration Guide, Version 6.3

850
 Firepower Threat Defense VPN
Deciding Which Authentication Method to Use

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.
• 1—Diffie-Hellman Group 1: 768-bit modulus. DH group 1 is considered insecure, please do not use it.
• 2—Diffie-Hellman Group 2: 1024-bit modulus. This option is no longer considered good protection.
• 5—Diffie-Hellman Group 5: 1536-bit modulus. Formerly considered good protection for 128-bit keys,
this option is no longer considered good protection.
• 14—Diffie-Hellman Group 14: 2048 bit modulus. Considered good protection for 192-bit keys.
• 19—Diffie-Hellman Group 19: 256 bit elliptic curve.
• 20—Diffie-Hellman Group 20: 384 bit elliptic curve.
• 21—Diffie-Hellman Group 21: 521 bit elliptic curve.
• 24—Diffie-Hellman Group 24: 2048-bit modulus and 256-bit prime order subgroup. This option is no
longer recommended.

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.

Firepower Management Center Configuration Guide, Version 6.3

851
 Firepower Threat Defense VPN
PKI Infrastructure and Digital Certificates

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
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 or ECDSA 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
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 426for 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:

Firepower Management Center Configuration Guide, Version 6.3

852
 Firepower Threat Defense VPN
VPN Topology Options

• Using the Simple Certificate Enrollment Protocol (SCEP) 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.

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.

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

853
 Firepower Threat Defense VPN
Hub and Spoke 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.

Firepower Management Center Configuration Guide, Version 6.3

854
 Firepower Threat Defense VPN
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.

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.

Firepower Management Center Configuration Guide, Version 6.3

855
 Firepower Threat Defense VPN
Implicit Topologies

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

Firepower Management Center Configuration Guide, Version 6.3

856
 CHAPTER 43
Site-to-Site VPNs for Firepower Threat Defense
• About Firepower Threat Defense Site-to-site VPNs, on page 857
• Managing Firepower Threat Defense Site-to-site VPNs, on page 859
• Configuring Firepower Threat Defense Site-to-site VPNs, on page 860

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 back-up peer configuration for point-to-point extranet VPN.
• 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.

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:

Firepower Management Center Configuration Guide, Version 6.3

857
 Firepower Threat Defense VPN
Firepower Threat Defense Site-to-site VPN Guidelines and Limitations

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

Firepower Management Center Configuration Guide, Version 6.3

858
 Firepower Threat Defense VPN
Managing Firepower Threat Defense Site-to-site VPNs

• 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 Hub, Spoke, and Full Mesh topologies; only point to
point VPN is supported. Additionally with Crypto ACL, there is no support for tunnel health events for
VPN topologies.
• 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.
• Transport mode is not supported, only tunnel mode. IPsec tunnel mode encrypts the entire original IP
datagram which becomes the payload in a new IP packet. Use tunnel mode when the firewall is protecting
traffic to and from hosts positioned behind a firewall. Tunnel mode is the normal way regular IPsec is
implemented between two firewalls (or other security gateways) that are connected over an untrusted
network, such as the Internet.

Managing Firepower Threat Defense Site-to-site VPNs

Smart License Classic License Supported Devices Supported Domains Access

Export-Compliance N/A FTD Leaf only Admin

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 463.
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 VPN > Firepower Threat Defense Device, and
continue as instructed in Configuring Firepower Threat Defense Site-to-site VPNs, on page 860:
Note VPNs topologies can be created only on leaf domains.

• Edit—To modify the settings of an existing VPN topology, click the edit icon ( ). 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 the delete icon ( ).

Firepower Management Center Configuration Guide, Version 6.3

859
 Firepower Threat Defense VPN
Configuring Firepower Threat Defense Site-to-site VPNs

• 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 919.
• Deploy—Click Deploy; see Deploy Configuration Changes, on page 308.
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

Smart License Classic License Supported Devices Supported Domains Access

Export-Compliance N/A FTD Leaf only Admin

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 Choose the Network Topology for this VPN.
Step 4 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 861.

Step 5 Required: Add Endpoints for this VPN deployment by clicking the add icon ( ) for each node in the topology.
Configure each endpoint field as described in FTD VPN Endpoint Options, on page 861.
• For Point to point, configure Node A and Node B.
• For Hub and Spoke, configure a Hub Node and Spoke Nodes
• For Full Mesh, configure multiple Nodes

Step 6 (Optional) Specify non-default IKE options for this deployment as described in FTD VPN IKE Options, on
page 863
Step 7 (Optional) Specify non-default IPsec options for this deployment as described in FTD VPN IPsec Options,
on page 864
Step 8 (Optional) Specify non-default Advanced options for this deployment as described in FTD Advanced Site-to-site
VPN Deployment Options, on page 866.
Step 9 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

860
 Firepower Threat Defense VPN
FTD VPN Endpoint Options

The endpoints are added to your configuration.

What to do next
Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Note Some VPN settings are validated only during deployment. Be sure to verify that your deployment was
successful.

FTD VPN Endpoint Options

Navigation Path
Devices > VPN > Site To Site. Then Add VPN > Firepower Threat Defense Device, or edit a listed VPN
Topology. Open the Endpoint tab.

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.
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.

Firepower Management Center Configuration Guide, Version 6.3

861
 Firepower Threat Defense VPN
FTD VPN Endpoint Options

• If you chose a managed device as an endpoint, choose a single IPv4 address or multiple IPv6
addresses from the drop-down list (these are the addresses already assigned to this interface on this
managed device).
• All endpoints in a topology must have the same IP addressing scheme. IPv4 tunnels can carry IPv6
traffic and vice-versa. The Protected Networks define which addressing scheme the tunneled traffic
will use.
• If the managed device is a high-availability container, choose from a list of interfaces.

This IP is Private
Check the check box if the endpoint resides behind a firewall with network address translation (NAT).
Public IP address
If you checked the This IP is Private check box, specify a public IP address for the firewall. If the
endpoint is a responder, specify this value.
Connection Type
Specify the allowed negotiation as bidirectional, answer-only, or originate-only. Supported combinations
for the connection type are:

Table 70: 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 the add icon ( ) 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 457 for details.
Protected Networks
Defines the networks that are protected by this VPN Endpoint. The networks may be marked by selecting
the list of Subnet/IP Address that define the networks that are protected by this endpoint. Click the add
icon ( ) to select from available Network Objects or add new Network Objects. See Creating Network
Objects, on page 372. 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.

Firepower Management Center Configuration Guide, Version 6.3

862
 Firepower Threat Defense VPN
FTD VPN IKE Options

Note 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 the add icon ( ) to add access control list objects.

Note Access Control List is supported only in the point to point topology.

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.

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 445
Authentication Type

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 preshared key
that is used for this VPN. Specify the Pre-shared Key Length, the number of characters in the key,
1-27.

Firepower Management Center Configuration Guide, Version 6.3

863
 Firepower Threat Defense VPN
FTD VPN IPsec Options

• Pre-shared Manual Key—Manually assign the preshared 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 PKI Enrollment Object. This enrollment object is
used to generate a trustpoint with the same name on the managed device. The trustpoint is created
when the PKI enrollment object is associated with that device.

For a full explanation of the options, see Deciding Which Authentication Method to Use, on page 851.

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 apply only in a hub-and-spoke VPN configuration. In a point-to-point
or full mesh VPN topology, you can apply only static crypto map policies. Emulate the use of
dynamic crypto-maps in a point-to-point topology by creating a hub-and-spoke topology with two
devices. Specify a dynamic IP address for the spoke, and enable dynamic crypto map on this topology.

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

Firepower Management Center Configuration Guide, Version 6.3

864
Firepower Threat Defense VPN
FTD VPN IPsec Options

tunnel mode, an attacker can only determine the tunnel endpoints and not the true source and
destination of the tunneled packets, even if they are the same as the tunnel endpoints.
• Transport preferred— Encapsulation mode is set to transport mode with an option to fallback to
tunnel mode if the peer does not support it. In Transport mode only the IP payload is encrypted,
and the original IP headers are left intact. Therefore, the admin must select a protected network that
matches the VPN interface IP address.
This mode has the advantages of adding only a few bytes to each packet and allowing devices on
the public network to see the final source and destination of the packet. With transport mode, you
can enable special processing (for example, QoS) on the intermediate network based on the
information in the IP header. However, the Layer 4 header is encrypted, which limits examination
of the packet.
• Transport required— Encapsulation mode is set to transport mode only, falling back to tunnel
mode is not allowed. If the endpoints cannot successfully negotiate transport mode, due to one
endpoint not supporting it, the VPN connection is not made.

Proposals
Click ( ) 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 449 and Configure IKEv2 IPsec Proposal Objects, on
page 449 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 850.
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.

Firepower Management Center Configuration Guide, Version 6.3

865
 Firepower Threat Defense VPN
FTD Advanced Site-to-site VPN Deployment Options

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.

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

866
 Firepower Threat Defense VPN
FTD VPN Advanced IPsec Options

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)
• 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.

Firepower Management Center Configuration Guide, Version 6.3

867
 Firepower Threat Defense VPN
FTD Advanced Site-to-site VPN Tunnel Options

• Enable Spoke to Spoke Connectivity through Hub—Disabled by default. Choosing this field enables
the devices on each end of the spokes to extend their connection through the hub node to the other device.

NAT Settings
• Keepalive Messages Traversal —Elect whether to enable NAT keepalive message traversal. NAT
traversal keepalive is used for the transmission of keepalive messages when there is a device (middle
device) located between a VPN-connected hub and spoke, and that device performs NAT on the IPsec
flow.
If you select this option, configure the Interval, in seconds, between the keepalive signals sent between
the spoke and the middle device to indicate that the session is active. The value can be from 5 to 3600
seconds. The default is 20 seconds.

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. 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.

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.

Firepower Management Center Configuration Guide, Version 6.3

868
 CHAPTER 44
Remote Access VPNs for Firepower Threat
Defense
• Firepower Threat Defense Remote Access VPN Overview, on page 869
• Remote Access VPN Features, on page 871
• Guidelines and Limitations for Remote Access VPNs , on page 872
• Prerequisites for Configuring Remote Access VPN, on page 874
• Create a New Remote Access VPN Policy, on page 874
• Managing Remote Access VPNs, on page 880
• Dynamic Authorization or RADIUS Change of Authorization (RADIUS CoA), on page 903
• Two-Factor Authentication, on page 905
• Custom Configurations with Remote Access VPNs , on page 906

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. It 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 these two types of remote access VPNs with basic capabilities. Then, enhance the policy configuration if
desired and deploy it to your Firepower Threat Defense secure gateway devices.

AnyConnect Client Profile and Editor

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 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 for Windows. It is an
independent program that you run outside of the Firepower Management Center.

Firepower Management Center Configuration Guide, Version 6.3

869
 Firepower Threat Defense VPN
Firepower Threat Defense Remote Access VPN Overview

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 login, if the secure gateway identifies the user as requiring the 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, it 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). Next the group profile is pushed to the VPN client and an IPsec security
association (SA) is created to complete the VPN.

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 463. 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.

Firepower Management Center Configuration Guide, Version 6.3

870
 Firepower Threat Defense VPN
Remote Access VPN Features

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. No facilities, such as SCEP or CA Services,
are provided to populate your clients with certificates.

The login information provided by a remote user is validated by an LDAP/AD realm or a RADIUS server
group. These entities are integrated with the Firepower Threat Defense secure gateway.

Note If users authenticate with RA VPN using Active Directory as the authentication source, users must log in
using their username. Logging in in 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 is blocked from, or allowed access to, your network resources.
See the About Identity Policies, on page 2139 and Getting Started with Access Control Policies, on page 1349
sections for more information.

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.
• IPv4 & IPv6. 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.

AAA
• Server authentication using self-signed or CA-signed identity certificates.
• AAA username and password-based remote authentication using RADIUS or LDAP/AD.
• RADIUS group and user authorization attributes, and RADIUS accounting.
• NGFW Access Control integration using VPN Identity.

Firepower Management Center Configuration Guide, Version 6.3

871
 Firepower Threat Defense VPN
Guidelines and Limitations for Remote Access VPNs

VPN Tunneling
• Address assignment
• Split tunneling
• 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, Client
Application.
• RA VPN events including authentication information such as username and OS platform.
• Tunnel statistics available using the FTD Unified CLI.

Guidelines and Limitations for Remote Access VPNs

Remote Access VPN Policy Configuration
• You can add a new RA VPN policy only by walking through the wizard. You must proceed through the
entire wizard to create a new policy; no policy will be saved if you cancel before completing the wizard.
• Two users should not edit an RA 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 a mis-configured NAT rule.
• Whenever IKE ports 500/4500 or SSL port 443 is in use or when there are some PAT translations that
are active, the AnyConnect 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 VPN 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 configuration 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 364.
• After you change the remote access VPN 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

Firepower Management Center Configuration Guide, Version 6.3

872
Firepower Threat Defense VPN
Guidelines and Limitations for Remote Access VPNs

memory and device model. Before deploying remote access VPN configuration changes, review the
Guidelines for Deploying Configuration Changes, on page 306.

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. RADIUS and
LDAP/AD authentication are supported.
• The LDAP/AD authorization and accounting are not supported for Remote Access VPN. Only RADIUS
server groups can be configured as authorization or accounting servers in the Remote Access VPN
configuration.
• Configure DNS on each device in the topology in order 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 if IP addresses are used.
You can configure DNS using the Platform Settings. For more information, see Configure DNS, on page
1093 and DNS Server Group Objects, on page 431.

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. No facilities, such as
SCEP or CA Services, are 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 as its own entity, it is only used to deploy the AnyConnect
Client.
The following AnyConnect features are not supported when connecting to a FTD secure gateway:
• Secure Mobility, Network Access Management, and all other AnyConnect modules and their profiles
beyond the core VPN capabilities and the VPN client profile.
• The following posture variants, Hostscan and Endpoint Posture Assessment, and any Dynamic Access
Policies based on the client posture.
• AnyConnect Customization and Localization support. The FTD device does not configure or deploy the
files necessary to configure AnyConnect for these capabilities.
• Custom Attributes for the AnyConnect Client are not supported on the FTD. Hence all features that make
use of Custom Attributes are not supported, such as: Deferred Upgrade on desktop clients and Per-App
VPN on mobile clients.
• Local authentication, VPN users cannot be configured on the FTD secure gateway.
Local CA, the secure gateway cannot act as a Certificate Authority.
• Secondary or Double Authentication using two sets of username and password from two AAA servers
for primary and secondary authentications.
• Single Sign-on using SAML 2.0.

Firepower Management Center Configuration Guide, Version 6.3

873
 Firepower Threat Defense VPN
Prerequisites for Configuring Remote Access VPN

• TACACS, Kerberos (KCD Authentication and RSA SDI).

• LDAP Authorization (LDAP Attribute Map).
• Browser Proxy.
• VPN Load balancing.

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 848.
• Configure the certificate enrollment object that is used to obtain the Identity Certificate for each Firepower
Threat Defense devices that act as remote access VPN gateways.
• 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.
• 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 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 379
• 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.

Create a New Remote Access VPN Policy

Note that you can add a new remote access VPN Policy only by walking through 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.

Firepower Management Center Configuration Guide, Version 6.3

874
Firepower Threat Defense VPN
Create a New Remote Access VPN Policy

Smart License Classic License Supported Devices Supported Domains Access

One of these AnyConnect N/A FTD Any Administrator

licenses associated with
your Smart License
account with Export
Controlled Features
enabled:
• AnyConnect VPN
Only
• AnyConnect Plus
• AnyConnect Apex

Before you begin

• Ensure that you complete all the prerequisites listed in Prerequisites for Configuring Remote Access
VPN, on page 874.

Procedure

Step 1 Choose Devices > VPN > Remote Access.

Step 2 Click ( ) 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 SSL or IPSec-IKEv2, or both the VPN protocols. Firepower Threat Defense supports SSL and
IPSec-IKEv2 protocols to establish secure connections over a public network through VPN tunnels.

Step 4 Configure the Connection Profile 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.

Step 5 Select the AnyConnect Client Image that the VPN users will use to connect to the remote access VPN.
The Cisco AnyConnect Secure Mobility client provides secure SSL or IPSec (IKEv2) connections to the
Firepower Threat Defense device for remote users with full VPN profiling to corporate resources. After the
remote access VPN policy is deployed on the Firepower Threat Defense device, VPN users can enter the IP
address of the configured device interface in their browser to download and install the AnyConnect client.

Step 6 Select the Network Interface and Identity Certificate.

Firepower Management Center Configuration Guide, Version 6.3

875
 Firepower Threat Defense VPN
Additional Configuration Requirements for Remote Access VPN

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
necessary) to complete a basic RA VPN Policy configuration. Then, deploy the configuration and establish
VPN connections.

Step 9 Deploy the remote access VPN policy; Deploy Configuration Changes, on page 308.

Additional Configuration Requirements for Remote Access VPN

After you create a new remote access VPN policy configuration using the wizard, complete the additional
configurations listed in the Summary page of the wizard for the remote access VPN policy to work on all
targeted devices.

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
on 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. For more
information, see Configure Access Interfaces for Remote Access VPN, on page 891.

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.

Firepower Management Center Configuration Guide, Version 6.3

876
 Firepower Threat Defense VPN
(Optional) Configure NAT Exemption

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.

(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), so you have greater control using NAT exemption than identity NAT. However,
unlike policy NAT, NAT exemption does not consider the ports in the access list. 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) On the Interface Objects tab, 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.

a) On the Translation tab, create the source and destination networks by selecting the following:
• Original Source and Translated Source

Firepower Management Center Configuration Guide, Version 6.3

877
 Firepower Threat Defense VPN
Configure DNS

• 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. Normally for identity NAT, proxy ARP is not required, and in some cases can cause connectivity
issues.

Step 6 Click Ok.

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 1093 and DNS Server Group Objects, on page 431.
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 451.

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.

Firepower Management Center Configuration Guide, Version 6.3

878
 Firepower Threat Defense VPN
(Optional) Configure Split Tunneling

Procedure

Step 1 Choose Devices > VPN > Remote Access.

Step 2 Select an existing remote access VPN policy in the list and click the corresponding Edit icon.
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 the Edit
icon.
Step 4 Click the Add icon 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.
c) Click Save.

(Optional) Configure Split Tunneling

Split tunnel is an optional configuration that can be added; split tunnel allows for VPN connectivity to a remote
network across a secure tunnel but also allows for a network outside VPN tunnel. 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 897.

Procedure

Step 1 Choose Devices > VPN > Remote Access.

Step 2 Select an existing Remote Access policy in the list and click the corresponding Edit icon.
Step 3 Select a connection profile and click the Edit icon.
Step 4 Click the Add icon 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
policy.
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 access list.
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 439

Firepower Management Center Configuration Guide, Version 6.3

879
 Firepower Threat Defense VPN
Managing Remote Access VPNs

Managing Remote Access VPNs

Smart License Classic License Supported Devices Supported Domains Access

One of these AnyConnect N/A FTD Any Administrator

licenses associated with
your Smart License
account with Export
Controlled Features
enabled:
• AnyConnect VPN
Only
• AnyConnect Plus
• AnyConnect Apex

Procedure

Step 1 Choose Devices > VPN > Remote Access.

Step 2 Select an existing remote access VPN policy in the list and click the corresponding Edit icon.
Step 3 To add or edit a Connection Profile, see Configure Connection Profile Settings, on page 880.
Step 4 To add or edit Access Interfaces, see Remote Access VPN Access Interface Options, on page 893.
Step 5 Choose the Advanced tab to complete the Remote Access VPN configuration:
a) To set up AnyConnect Client Images, see Cisco AnyConnect Secure Mobility Client Image, on page
894.
b) To set up the Address Assignment Policy, see Remote Access VPN Address Assignment Policy, on page
895.
c) To configure Certificate Maps for this connection profile, see Configure Certificate Maps, on page 896.
d) Choose Group Policies from the navigation pane to add more Group Policies that can be assigned to
remote users using this connection profile. These are in addition to the default group policy specified
when the profile was created. See Configuring Group Policies, on page 897.
e) To edit IPsec options, see Configuring IPsec Settings for Remote Access VPNs, on page 897.

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.

Firepower Management Center Configuration Guide, Version 6.3

880
 Firepower Threat Defense VPN
Configure Multiple Connection Profiles

Procedure

Command or Action Purpose

Step 1 Choose Devices > VPN > Remote Access.
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 the The edit connection profile page is displayed.
corresponding Edit icon.
Step 4 (Optional) Add multiple connection profiles. Configure Multiple Connection Profiles, on
page 881
Step 5 Configure IP Addresses for VPN Clients. Configure IP Addresses for VPN Clients, on
page 882
Step 6 (Optional) Update AAA Settings for remote Remote Access VPN AAA Settings, on page
access VPNs. 883
Step 7 (Optional) Create or update Aliases. Create or Update Aliases for a Connection
Profile, on page 890
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
DfaultWEBVPNGroup.

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 2 Select an existing remote access VPN policy in the list and click the corresponding Edit icon.
Step 3 Click the Add icon 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.

Firepower Management Center Configuration Guide, Version 6.3

881
 Firepower Threat Defense VPN
Configure IP Addresses for VPN Clients

c) AAA— Configure the AAA servers to enable managed devices acting as secure VPN gateways to determine
who a user is (authentication), what the user is permitted to do (authorization), and what the user did
(accounting).
d) Aliases—Provide an alternate name or URL for the connection profile. Remote Access VPN administrators
can enable or disable the Alias names and Alias URLs. VPN users can choose an Alias name when they
connect to the Firepower Threat Defense device remote access VPN using the AnyConnect VPN client.
Step 4 Click Save.

Related Topics
Configure Connection Profile Settings, on page 880

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 to 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 the Connection Profile's associated
group-policy, 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 458.

Procedure

Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Existing remote access policies are listed.
Step 2 Select an existing remote access VPN policy in the list and click the corresponding Edit icon.
Step 3 Select the connection profile that you want to update and click the corresponding Edit icon, and then select
the Client Address Assignment tab.
Step 4 Select the following for Address Pools :
a) Click the Add icon 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.

Firepower Management Center Configuration Guide, Version 6.3

882
 Firepower Threat Defense VPN
Remote Access VPN AAA Settings

b) Select the Add icon in the Address Pools window to add a new IPv4 address 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 458.
c) Click OK.
Step 5 Select the following for DHCP Servers:
Note The DHCP server address can be configured only with IPv4 address.
a) Specifies the name and DHCP (Dynamic Host Configuration Protocol) server address as network objects.
Select the Add icon and choose the server from the object list. To delete a DHCP server, select the Delete
icon in that row.
b) Select the Add icon in the New Network Objects window 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 372 and Allowing Object Overrides, on page 369.
c) Click OK.
Step 6 Click Save.

Related Topics
Configure Connection Profile Settings, on page 880

Remote Access VPN AAA Settings

AAA servers enable managed devices acting as secure gateways to determine who a user is (authentication),
what the user is permitted to do (authorization), and what the user did (accounting). Some examples of the
AAA servers are RADIUS, LDAP/AD, TACACS+, and Kerberos. For Remote Access VPN on Firepower
Threat Defense devices, AD, LDAP, and RADIUS AAA servers are supported for authentication. Only
RADIUS servers can be configured and used for authorization and accounting servers. Please refer to
Understanding Policy Enforcement of Permissions and Attributes to understand more about remote access
VPN authorization.

Note Before you add or edit the Remote Access VPN policy, you must configure the Realm and RADIUS server
groups you want to specify. For more information, see Create a Realm, on page 2092 and RADIUS Server
Groups, on page 459.
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.

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:

Firepower Management Center Configuration Guide, Version 6.3

883
 Firepower Threat Defense VPN
Understanding AAA Server Connectivity

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

884
 Firepower Threat Defense VPN
RADIUS Server Attributes for Firepower Threat Defense

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 637.
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.
• 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.

RADIUS Server Attributes for Firepower Threat Defense

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.

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.

Firepower Management Center Configuration Guide, Version 6.3

885
 Firepower Threat Defense VPN
RADIUS Server Attributes for Firepower Threat Defense

• 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 71: 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 72: RADIUS Attributes Sent to Firepower Threat Defense

Attribute Single or
Attribute Number Syntax, Type Multi-valued Description or Value

Access-List-Inbound 86 String Single Both of the Acess-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.

Downloadable ACLs Cisco-AV-Pair merge-dacl Supported via Cisco-AV-Pair configuration.

{before-avpair
|
after-avpair}

Firepower Management Center Configuration Guide, Version 6.3

886
 Firepower Threat Defense VPN
Configure AAA Settings for Remote Access VPN

Attribute Single or
Attribute Number Syntax, Type Multi-valued Description or Value

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.

Configure AAA Settings for Remote Access VPN

Smart License Classic License Supported Devices Supported Domains Access

One of these AnyConnect N/A FTD Any Administrator

licenses associated with
your Smart License
account with Export
Controlled Features
enabled:
• AnyConnect VPN
Only
• AnyConnect Plus
• AnyConnect Apex

Procedure

Step 1 Choose Devices > VPN > Remote Access.

Step 2 Select an existing remote access VPN policy in the list and click the corresponding Edit icon.

Firepower Management Center Configuration Guide, Version 6.3

887
 Firepower Threat Defense VPN
Configure AAA Settings for Remote Access VPN

Step 3 Select a connection profile to update AAA settings, click the corresponding Edit icon and then click the AAA
tab.
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 & 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 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)

Firepower Management Center Configuration Guide, Version 6.3

888
Firepower Threat Defense VPN
Configure AAA Settings for Remote Access VPN

• UID (User ID)

• UPN (User Principal Name)

• Client Certificate & AAA—Both types of authentication are performed, see AAA Only and Client
Certificate Only descriptions.
Whichever authentication method you choose, select or deselect Allow connection only if user
exists in authorization database.

• Authentication Server—Authentication is the way a user is identified before being allowed access to
the network and network services. Authentication requires valid user credentials, a certificate, or both.
You can use authentication alone or with authorization and accounting.
Enter or select an LDAP or AD realm or a RADIUS server group that has been previously configured
to authenticate Remote Access VPN users.

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. Were you
not to use authorization, authentication alone would provide the same access to all authenticated users.
Authorization requires authentication. Only RADIUS servers are supported for Authorization services.
To know more about how remote access VPN authorization works, please refer to the section
Understanding Policy Enforcement of Permissions and Attributes.
Enter or select a RADIUS server group object that has been pre-configured to authorize Remote Access
VPN users.
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 obtained AAA server attributes 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.

Step 6 Select the following for Accounting:

• Accounting Server—Accounting is used to track the services that users are accessing, as well as 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 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.

Firepower Management Center Configuration Guide, Version 6.3

889
 Firepower Threat Defense VPN
Create or Update Aliases for a Connection Profile

Enter or select 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.

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 1 Choose Devices > VPN > Remote Access.

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 the corresponding Edit icon.
Step 4 Click the Aliases tab.
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 377.
c) Select the Enabled check box in each window to enable the aliases.

Firepower Management Center Configuration Guide, Version 6.3

890
 Firepower Threat Defense VPN
Configure Access Interfaces for Remote Access VPN

d) Click OK.
• Click the Edit icon to edit the Alias name or the Alias URL.
• To delete an Alias name or the Alias URL, click the Delete icon in that row.

Step 7 Click Save.

Related Topics
Configure Connection Profile Settings, on page 880

Configure Access Interfaces for Remote Access VPN

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.

Smart License Classic License Supported Devices Supported Domains Access

One of these AnyConnect N/A FTD Any Administrator

licenses associated with
your Smart License
account with Export
Controlled Features
enabled:
• AnyConnect VPN
Only
• AnyConnect Plus
• AnyConnect Apex

Procedure

Step 1 Choose Devices > VPN > Remote Access.

Step 2 Select an existing remote access VPN policy in the list and click the corresponding Edit icon.
Step 3 Click the Access Interface tab.
Step 4 To add an access interface, select the Add icon 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. Select the
value from the drop-down list.
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.

Firepower Management Center Configuration Guide, Version 6.3

891
 Firepower Threat Defense VPN
Configure Access Interfaces for Remote Access VPN

• Enable SSL—Select this option to enable SSL settings.

• Select Enable Datagram Transport Layer Security.
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.
• 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 SSL Global Identity certificate. Select the option from the
drop-down list. The 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 876.

Step 9 Click Save to save the access interface changes.

Related Topics
Interface Objects: Interface Groups and Security Zones, on page 379

Firepower Management Center Configuration Guide, Version 6.3

892
 Firepower Threat Defense VPN
Remote Access VPN Access Interface Options

Remote Access VPN Access Interface Options

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. For more information about adding an access interface, see
Configure Access Interfaces for Remote Access VPN, on page 891
To edit an access interface, select the Edit icon in that row. To delete an access interface, select the Delete
icon in that row.

Access Settings
• Allow Users to select connection profile will 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.
For SSL Settings, use the following information:
• 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—Specifies the SSL Global Identity certificate. Select the option from
the drop-down list. The SSL Global Identity Certificate will be used for all the associated interfaces
if the Interface Specific Identity Certificate is not provided.
For IPsec-IKEv2 Settings, use the following information:
• IKEv2 Identity Certificate—Specifies the IKEv2 identity certificate.
• 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. 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 876.

Related Topics
FTD Remote Access VPN IPsec/IKEv2 Parameters Page
About SSL Settings, on page 1103
Configure Access Interfaces for Remote Access VPN, on page 891
Aliases and Alias URLs

Firepower Management Center Configuration Guide, Version 6.3

893
 Firepower Threat Defense VPN
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 the 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.
You can 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 894

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 456. For more information
about the client image, see Cisco AnyConnect Secure Mobility Client Image, on page 894.
Click the Show re-order buttons link to view a specific client image, when additional client images are
available for a particular operating system.

Note To delete an already installed Cisco AnyConnect client image, click the Delete icon in that row.

Firepower Management Center Configuration Guide, Version 6.3

894
 Firepower Threat Defense VPN
Remote Access VPN Address Assignment Policy

Smart License Classic License Supported Devices Supported Domains Access

One of these AnyConnect N/A FTD Any Administrator

licenses associated with
your Smart License
account with Export
Controlled Features
enabled:
• AnyConnect VPN
Only
• AnyConnect Plus
• AnyConnect Apex

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 the Add icon in the Available AnyConnect Images portion of the AnyConnect Images dialog.
Step 3 Enter the Name, File Name, and Description for the available AnyConnect Image.
Step 4 Click Browse to navigate to the location for selecting the client image to be uploaded.
Step 5 Click Save to upload the image in the Firepower Management Center.
Once you upload the client image to the Firepower Management Center, the operating system displays platform
information for the image that you uploaded to the Firepower Management Center.

Related Topics
Cisco AnyConnect Secure Mobility Client Image, on page 894

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
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.

Firepower Management Center Configuration Guide, Version 6.3

895
 Firepower Threat Defense VPN
Configure Certificate Maps

• 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
Configure Connection Profile Settings, on page 880
Remote Access VPN AAA Settings, on page 883

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 457.

Procedure

Step 1 Choose Devices > VPN > Remote Access.

Step 2 Select an existing remote access VPN policy in the list and click the corresponding Edit icon.
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
• 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.

Firepower Management Center Configuration Guide, Version 6.3

896
 Firepower Threat Defense VPN
Configuring Group Policies

Step 6 Click Save.

Configuring Group Policies

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.

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Admin

Procedure

Step 1 Choose Devices > VPN > Remote Access.

Step 2 Select an existing remote access VPN policy in the list and click the corresponding Edit icon.
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 at RA VPN policy creation time. Click Add.
Use the Refresh and Search utilities to locate the group policy. Add a new Group Policy object if necessary.

Step 5 Click OK when you have the Selected Group Policy window set as desired.

Related Topics
Configure Group Policy Objects, on page 451

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 891 for more information.

Firepower Management Center Configuration Guide, Version 6.3

897
 Firepower Threat Defense VPN
Configure Remote Access VPN Crypto Maps

Smart License Classic License Supported Devices Supported Domains Access

One of these AnyConnect N/A FTD Any Administrator

licenses associated with
your Smart License
account with Export
Controlled Features
enabled:
• AnyConnect VPN
Only
• AnyConnect Plus
• AnyConnect Apex

Procedure

Step 1 Choose Devices > VPN > Remote Access.

Step 2 From the list of available VPN policies, select the policy for which you want to modify the settings.
Step 3 Click the Advanced tab.
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 898. You can add or remove interface
groups to the selected VPN policy in the Access Interface tab. See Configure Access Interfaces for Remote
Access VPN, on page 891 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 901 for more information. To add a new IKE policy, see Configure IKEv2 Policy Objects , on
page 447. 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 902 for more information.
Step 5 Click Save.

Configure Remote Access VPN Crypto Maps

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 the Access Interface tab. See Configure
Access Interfaces for Remote Access VPN, on page 891 for more information.

Firepower Management Center Configuration Guide, Version 6.3

898
Firepower Threat Defense VPN
Configure Remote Access VPN Crypto Maps

Smart License Classic License Supported Devices Supported Domains Access

One of these AnyConnect N/A FTD Any Administrator

licenses associated with
your Smart License
account with Export
Controlled Features
enabled:
• AnyConnect VPN
Only
• AnyConnect Plus
• AnyConnect Apex

Procedure

Step 1 Choose Devices > VPN > Remote Access.

Step 2 From the list of available VPN policies, select the policy for which you want to modify the settings.
Step 3 Click the Advanced > Crypto Maps, and select a row in the table and click the Edit icon 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.
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:

Firepower Management Center Configuration Guide, Version 6.3

899
 Firepower Threat Defense VPN
Configure Remote Access VPN Crypto Maps

• 1—Diffie-Hellman Group 1 (768-bit modulus).

• 2—Diffie-Hellman Group 2 (1024-bit modulus).
• 5—Diffie-Hellman Group 5 (1536-bit modulus, considered good protection for 128-bit keys, but group
14 is better). If you are using AES encryption, use this group (or higher).
• 14—Diffie-Hellman Group 14 (2048-bit modulus, considered good protection for 128-bit keys).
• 19—Diffie-Hellman Group 19 (256-bit elliptical curve field size).
• 20—Diffie-Hellman Group 20 (384-bit elliptical curve field size).
• 21—Diffie-Hellman Group 21 (521-bit elliptical curve field size).
• 24—Diffie-Hellman Group 24 (2048-bit modulus and 256-bit prime order subgroup).

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.

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

Firepower Management Center Configuration Guide, Version 6.3

900
 Firepower Threat Defense VPN
IKE Policies in Remote Access VPNs

Step 11 Click OK.

Related Topics
Interface Objects: Interface Groups and Security Zones, on page 379

IKE Policies in Remote Access VPNs

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.

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 901.

Note FTD supports only IKEv2 for remote access VPNs.

Procedure

Step 1 Choose Devices > VPN > Remote Access.

Step 2 From the list of available VPN policies, select the policy for which you want to modify the settings.
Step 3 Click Advanced > IKE Policy.
Step 4 Click the Add button 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).

Firepower Management Center Configuration Guide, Version 6.3

901
 Firepower Threat Defense VPN
Configure Remote Access VPN IPsec/IKEv2 Parameters

• 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, on page 893

Configure Remote Access VPN IPsec/IKEv2 Parameters

Procedure

Step 1 Choose Devices > VPN > Remote Access.

Step 2 From the list of available VPN policies, select the policy for which you want to modify the settings.
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.

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:

Firepower Management Center Configuration Guide, Version 6.3

902
 Firepower Threat Defense VPN
Dynamic Authorization or RADIUS Change of Authorization (RADIUS CoA)

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

Dynamic Authorization or RADIUS Change of Authorization

(RADIUS CoA)
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, 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.

Firepower Management Center Configuration Guide, Version 6.3

903
 Firepower Threat Defense VPN
Configuring RADIUS Dynamic Authorization

Related Topics
RADIUS Server Groups, on page 459
Interface Objects: Interface Groups and Security Zones, on page 379
Configuring RADIUS Dynamic Authorization, on page 904
RADIUS Server Attributes for Firepower Threat Defense, on page 885

Configuring RADIUS Dynamic Authorization

Smart License Classic License Supported Devices Supported Domains Access

One of these AnyConnect N/A FTD Any Administrator

licenses associated with
your Smart License
account with Export
Controlled Features
enabled:
• AnyConnect VPN
Only
• AnyConnect Plus
• AnyConnect Apex

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.

Procedure

Command or Action Purpose

Step 1 Log on to your Firepower Management Center
web interface.
Step 2 Configure a RADIUS server object with RADIUS Server Group Options, on page 460
dynamic authorization.
Step 3 Configure a route to ISE server through an RADIUS Server Group Options, on page 460
interface enabled for change of authorization
Configure ISE/ISE-PIC for User Control, on
(CoA) to establish connectivity from Firepower
page 2107
Threat Defense to RADIUS server through
routing or a specific interface.

Firepower Management Center Configuration Guide, Version 6.3

904
 Firepower Threat Defense VPN
Two-Factor Authentication

Command or Action Purpose

Step 4 Configure a remote access VPN policy and Create a New Remote Access VPN Policy, on
select the RADIUS server group object that you page 874
have created with dynamic authorization.
Step 5 Configure the DNS server details and Configure DNS, on page 1093
domain-lookup interfaces using the Platform
DNS Server Group Objects, on page 431
Settings. See and.
Step 6 Configure a split-tunnel in group policy to allow Configure Group Policy Objects, on page 451
DNS traffic through Remote Access VPN
tunnel if the DNS server is reachable through
VNP network.
Step 7 Deploy the configuration changes. Deploy Configuration Changes, on page 308

Related Topics
Interface Objects: Interface Groups and Security Zones, on page 379

Two-Factor Authentication
Configuring RSA Two-Factor Authentication
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.

Smart License Classic License Supported Devices Supported Domains Access

One of these AnyConnect N/A FTD Any Administrator

licenses associated with
your Smart License
account with Export
Controlled Features
enabled:
• AnyConnect VPN
Only
• AnyConnect Plus
• AnyConnect Apex

Firepower Management Center Configuration Guide, Version 6.3

905
 Firepower Threat Defense VPN
Custom Configurations with Remote Access VPNs

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.

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.

Procedure

Command or Action Purpose

Step 1 Log on to your Firepower Management Center
web interface.
Step 2 Create a RADIUS server group. RADIUS Server Group Options, on page 460

Step 3 Create a RADIUS Server object within the new RADIUS Server Options, on page 461
RADIUS server group, with RADIUS or AD
Note The RADIUS or AD server must be
server as the host and with a timeout of 60
the same server that is configured as
seconds or more.
the authentication agent in RSA
server.

Step 4 Configure a new remote access VPN policy Create a New Remote Access VPN Policy, on
using the wizard or edit an existing remote page 874
access VPN policy.
Step 5 Select RADIUS as the authentication server and Configure AAA Settings for Remote Access
then select the newly-created RADIUS server VPN, on page 887
group as the authentication server.
Step 6 Deploy the configuration changes. Deploy Configuration Changes, on page 308

Custom Configurations with Remote Access VPNs

This section provides information about specific configurations that you can perform with Firepower Threat
Defense remote access VPNs, in addition to the basic settings you can configure using the wizard and the
configurations listed in Managing Remote Access VPNs, on page 880.

Firepower Management Center Configuration Guide, Version 6.3

906
 Firepower Threat Defense VPN
Update AnyConnect Images for Remote Access VPN Clients

These configurations help an administrator to configure specific remote access VPN privileges to a set of
users or user groups based on the organization's requirements.

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 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select an existing remote access policy in the list and click the corresponding Edit icon.
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 the Add icon 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

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.

Firepower Management Center Configuration Guide, Version 6.3

907
 Firepower Threat Defense VPN
Authenticate VPN Users via Client Certificates

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 874.
• On your Firepower Management Center web interface, go to Objects > Object Management > VPN >
AnyConnect File and add the new AnyConnect client image.

Procedure

Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select an existing remote access VPN policy in the list and click the corresponding Edit icon.
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 the Add icon 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 they connect to the remote
access VPN gateway.

Related Topics
Configure Group Policy Objects, on page 451

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

Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select an existing remote access policy in the list and click the corresponding Edit icon; 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 On the AAA tab, select the Authentication Method, Client Certificate Only.

Firepower Management Center Configuration Guide, Version 6.3

908
Firepower Threat Defense VPN
Authenticate VPN Users via Client Certificates

With this authentication method, the user is authenticated using a client certificate. You must configure the
client certificate on VPN client endpoints. By default, the user name is derived from client certificate fields
CN and OU respectively. If the user name is specified in other fields in the client certificate, use 'Primary'
and 'Secondary' field to map appropriate fields.
If you select Map specific field option, which includes the username from the client certificate. The Primary
and Secondary fields display the following default values, respectively: CN (Common Name) and OU
(Organisational Unit) respectively. If you select the Use entire DN as username option, the system
automatically retrieves the user identity. A distinguished name (DN) is a unique identification, made up of
individual fields, that can be used as the identifier when matching users to a connection profile. DN rules are
used for enhanced certificate authentication.
• Primary and Secondary fields pertaining to the Map specific field option contains these common values:
• C (Country)
• CN (Common Name)
• DNQ (DN Qualifier
• EA (Email Address)
• GENQ (Generational Qualifier)
• GN (Given Name)
• I (Initial)
• L (Locality)
• N (Name)
• O (Organisation)
• OU (Organisational Unit)
• SER (Serial Number)
• SN (Surname)
• SP (State Province)
• T (Title)
• UID (User ID)
• UPN (User Principal Name)

• Whichever authentication method you choose, select or deselect Allow connection only if user exists
in authorization database.

Related Topics
Configure Connection Profile Settings, on page 880
Adding Certificate Enrollment Objects, on page 427

Firepower Management Center Configuration Guide, Version 6.3

909
 Firepower Threat Defense VPN
Configure Remote Access VPN Login via Client Certificate and AAA Server

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 sever,
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 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select an existing remote access policy in the list and click the corresponding Editicon; 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 On the AAA tab, select the 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
Authorization Server and Accounting Server respectively.
• 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.
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.
Primary and Secondary fields pertaining to the Map specific field option contains these common
values:
• C (Country)
• CN (Common Name)
• DNQ (DN Qualifier

Firepower Management Center Configuration Guide, Version 6.3

910
 Firepower Threat Defense VPN
Configure Multiple Connection Profiles

• EA (Email Address)
• GENQ (Generational Qualifier)
• GN (Given Name)
• I (Initial)
• L (Locality)
• N (Name)
• O (Organisation)
• OU (Organisational Unit)
• SER (Serial Number)
• SN (Surname)
• SP (State Province)
• T (Title)
• UID (User ID)
• UPN (User Principal Name)

• Whichever authentication method you choose, select or deselect Allow connection only if user
exists in authorization database.

Related Topics
Configure Connection Profile Settings, on page 880
Adding Certificate Enrollment Objects, on page 427

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
DfaultWEBVPNGroup.

Before you begin

Ensure that you have configured remote access VPN using the Remote Access Policy wizard with a connection
profile.

Firepower Management Center Configuration Guide, Version 6.3

911
 Firepower Threat Defense VPN
Manage Password Changes over VPN Sessions

Procedure

Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Existing remote access policies are listed.
Step 2 Select an existing remote access VPN policy in the list and click the corresponding Edit icon.
Step 3 Click the Add icon and specify the following in the Add Connection Profile window:
a) Connection Profile—Provide a name that the remote users will use for VPN connections. The connection
profile contains a set of parameters that define how the remote users connect to the VPN device.
b) Client Address Assignment— Assign IP Address for the remote clients from the local IP Address pools,
DHCP servers, and AAA servers.
c) AAA— Configure the AAA servers to enable managed devices acting as secure VPN gateways to determine
who a user is (authentication), what the user is permitted to do (authorization), and what the user did
(accounting).
d) Aliases—Provide an alternate name or URL for the connection profile. Remote Access VPN administrators
can enable or disable the Alias names and Alias URLs. VPN users can choose an Alias name when they
connect to the Firepower Threat Defense device remote access VPN using the AnyConnect VPN client.
Step 4 Click Save.

Related Topics
Configure Connection Profile Settings, on page 880

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 887.

Procedure

Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select an existing remote access policy in the list and click the corresponding Edit icon.
Step 3 Select the connection profile that includes AAA settings and click Edit > AAA > Password Management.
Step 4 Select Enable Password Management.
Step 5 Select to notify users ahead of password expiry and specify the number of days; or, select to notify users on
the day the password expires.
Step 6 Click Save.

Related Topics
Configure Connection Profile Settings, on page 880

Firepower Management Center Configuration Guide, Version 6.3

912
 Firepower Threat Defense VPN
Restrict Connection Profile Selection to a User Group

Restrict Connection Profile Selection to 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 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select an existing remote access policy in the list and click the corresponding Edit icon.
Step 3 Select the Access Interfaces tab and disable Allow users to select the connection profile while logging in.
Step 4 Click Advanced > Certificate Maps.
Step 5 Select the Use the configured rules to match a certificate to a Connection Profile checkbox.
Step 6 Select the Certificate Map Name or click the Add icon to add a certificate rule.
Step 7 Select the Connection Profile, and click Ok.
With this configuration, when a user connects from the AnyConnect client, the user will have the mapped
connection profile and will be authenticated to use the VPN.

Related Topics
Configure Group Policy Objects, on page 451
Configure Connection Profile Settings, on page 880

Configure LDAP or Active Directory for Authorization

When you want to configure remote access VPN with LDAP or Active Directory (AD) server for authorization,
you must configure an attribute map using a FlexConfig object as the attribute map is not supported directly
on Firepower Management Center web interface.

Firepower Management Center Configuration Guide, Version 6.3

913
 Firepower Threat Defense VPN
Configure LDAP or Active Directory for Authorization

Before you begin

Ensure that you have created a Realm object for LDAP or AD.

Procedure

Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Create a remote access VPN policy with LDAP or AD realm object as the authentication server. Or edit an
existing remote access VPN configuration and select LDAP or AD realm as the authentication server.
Step 3 Choose Objects > Object Management > FlexConfig > FlexConfig Object.
Step 4 Create a FlexConfig policy and create and assign the following two FlexConfig objects in the append section:
See Configure the FlexConfig Policy, on page 981.
a) Create the FlexConfig Object for LDAP Attribute Map with Deployment type: Once and Type: Append.
Enter the following in the object body:
lda attribute-map <LDAP_Map_for_VPN_Access>
map-name memberOf Group-Policy
map-value memberOf CN=APP-SSL-VPN Managers,CN=Users,OU=stbu,DC=cisco,DC=com
LabAdminAccessGroupPolicy
map-value memberOf CN=cisco-Eng,CN=Users,OU=stbu,DC=cisco,DC=com
VPNAccessGroupPolicy

b) Create a FlexConfig Object associating the LDAP attribute map to the LDAP AAA-server, with
Deployment type: Everytime and Type: Append.
Note This mapping is required to reinstate the LDAP-attribute-map association because it is negated
by Firepower Management Center.

Enter the following in the object body area:

aaa-server <LDAP/AD_Realm_name> host <AD Server IP>
ldap-attribute-map <LDAP_Map_for_VPN_Access>
exit

Use the same aaa-server same as the LDAP realm name used in the AAA server settings of the connection
profile that you have added to the remote access VPN policy configuration.

For more information, see Configure FlexConfig Text Objects, on page 979.
a) Click Save.
Make sure the order of the FlexConfig objects in the FlexConfig Policy is the LDAP Attribute Map FlexConfig
object followed by the AAA-server object.
This will configure the LDAP attribute map and associate it with the LDAP server configuration on the
Firepower Threat Defense device.

Related Topics
Configure FlexConfig Objects, on page 975

Firepower Management Center Configuration Guide, Version 6.3

914
 Firepower Threat Defense VPN
Delegate the Selection of Group Policy or Other Attributes to the Authorization Server

Delegate the Selection of Group Policy or Other Attributes to the Authorization

Server
When a remote access VPN user connects to the VPN, the group policy configured in the connection profile
is assigned to the user. However the remote access VPN system administrator can configure to override the
group policy when a RADIUS server or ISE is configured for user authorization. The administrator can
configure multiple authorization attributes specific for users or user-groups. Once users are authenticated,
these specific authorization attributes are pushed to the Firepower Threat Defense device.
Configure ISE or the RADIUS Server to set the Authorization Profile for a user or user-group to send IETF
RADIUS Attribute 25 and map to the corresponding Group Policy name, or push a Downloadable ACL, set
a banner, restrict VLAN, and configure the advanced option of applying an SGT to the session.
The obtained authorization server attributes override the attribute values that may have been previously
configured on the Group Policy or the Connection Profile. A Group Policy is a set of user-oriented
attribute-value pairs for Remote Access VPN users. These attributes are applied to all users that are part of
that group when the VPN connection is established.

Before you begin

Ensure that you configure a remote access VPN policy with RADIUS server or ISE as the authentication
server.

Procedure

Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select an existing remote access VPN policy in the list and click the corresponding Edit icon.
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.
You can map a single group policy to a connection profile; but you can create multiple group policies in a
remote access VPN policy. These group policies can be 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 attribute number 25. You can use
one of the following formats:
group policy name
OU=group policy name
OU=group policy name;

When the group policy is configured in the authorization server, the group policy overrides the group policy
configured in the connection profile for the remote access VPN user after the user is authenticated.

Firepower Management Center Configuration Guide, Version 6.3

915
 Firepower Threat Defense VPN
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. But 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.
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, or 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.

Before you begin

Ensure that you configure a remote access VPN policy with RADIUS as the authentication server.

Procedure

Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select an existing remote access policy in the list and click the corresponding Edit icon.
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.
You can map only one group policy to a connection profile; but you can create multiple group policies in a
remote access VPN policy. These group policies can be referenced in ISE or the RADIUS server and configured
to override the group policy configured in the connection profile by assigning the authorization attributes in
the authorization server.

Step 5 Deploy the configuration on the target Firepower Threat Defense device.
Step 6 On the authorization server, create an Authorization Profile with RADIUS attributes for IP address and
downloadable ACLs.
When the group policy is configured in the authorization server selected for remote access VPN, the group
policy overrides the group policy configured in the connection profile for the remote access VPN user after
the user is authenticated.

Related Topics
Configure Group Policy Objects, on page 451

Denying 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.

Firepower Management Center Configuration Guide, Version 6.3

916
 Firepower Threat Defense VPN
Send Accounting Records to the RADIUS Server

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.

Procedure

Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select an existing remote access policy in the list and click the corresponding Edit icon.
Step 3 Select Advanced > Group Policies.
Step 4 Select a group policy and click the Edit icon 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.

Related Topics
Configure Connection Profile Settings, on page 880

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 460.
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.

Firepower Management Center Configuration Guide, Version 6.3

917
 Firepower Threat Defense VPN
Send Accounting Records to the RADIUS Server

Procedure

Step 1 On your Firepower Management Center web interface, choose Devices > VPN > Remote Access.
Step 2 Select an existing remote access policy in the list and click the corresponding Edit icon, or create a new remote
access VPN policy.
Step 3 Select the connection profile that includes AAA settings and click Edit > AAA.
Step 4 Select a RADIUS server as the Accounting Server.
Step 5 Click Save.

Related Topics
Configure Connection Profile Settings, on page 880
Configure AAA Settings for Remote Access VPN, on page 887

Firepower Management Center Configuration Guide, Version 6.3

918
 CHAPTER 45
VPN Monitoring for Firepower Threat Defense
This chapter describes Firepower Threat Defense VPN monitoring tools, parameters, and statistics information.
• VPN Summary Dashboard, on page 919
• VPN Session and User Information, on page 920
• VPN Health Events, on page 921

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

Smart License Classic License Supported Devices Supported Domains Access

Export-Compliance N/A FTD Leaf only Admin

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.

Procedure

Step 1 Choose Overview > Dashboards > Access Controlled User Statistics, and then choose the VPN dashboard.
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.

Firepower Management Center Configuration Guide, Version 6.3

919
 Firepower Threat Defense VPN
VPN Session and User Information

• VPN Users by Client Country.

What to do next
The VPN dashboard is a complex, highly customizable monitoring feature that provides exhaustive data.
• For complete information on how to use dashboards in the Firepower System, see Dashboards, on page
217.
• For information on how to modify the VPN dashboard widgets, see Configuring Widget Preferences, on
page 233.

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.
• To learn more about active sessions; see Viewing Active Session Data, on page 2647.
• To learn more about the contents of the columns in the active sessions table; see Active Sessions, Users,
and User Activity Data, on page 2640.

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 2652.
• To learn more about the contents of the columns in the user activity table; see Active Sessions, Users,
and User Activity Data, on page 2640.

Firepower Management Center Configuration Guide, Version 6.3

920
 Firepower Threat Defense VPN
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:
• VPN for 7000 & 8000 Series (7000 & 8000 Series)
• Site-to-site VPN for Firepower Threat Defense
• Remote access VPN for Firepower Threat Defense

See Health Monitoring, on page 239 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

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Maint/Any

Security Analyst

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.

Procedure

Step 1 Choose System > Health > Events.

Step 2 Select VPN Status under the Module Name column.
See Health Event Views, on page 261 for more details on system health events.

Firepower Management Center Configuration Guide, Version 6.3

921
 Firepower Threat Defense VPN
Viewing VPN Health Events

Firepower Management Center Configuration Guide, Version 6.3

922
 CHAPTER 46
VPN Troubleshooting for Firepower Threat
Defense
This chapter describes Firepower Threat Defense VPN troubleshooting tools and debug information.
• System Messages, on page 923
• VPN System Logs, on page 923
• Debug Commands, on page 924

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 in the System
Status icon, located to the immediate right of the Deploy button in the main menu. See System Messages,
on page 279 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 Configure Syslog, on page 1113 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.

Firepower Management Center Configuration Guide, Version 6.3

923
 Firepower Threat Defense VPN
Viewing VPN System Logs

Viewing VPN System Logs

Smart License Classic License Supported Devices Supported Domains Access

Export-Compliance N/A FTD Leaf only Admin

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.

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 Configure Syslog, on page 1113 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]

Firepower Management Center Configuration Guide, Version 6.3

924
 Firepower Threat Defense VPN
Debug Commands

no debug feature [subfeature]

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:

Firepower Management Center Configuration Guide, Version 6.3

925
 Firepower Threat Defense VPN
debug aaa

INFO: jdoe

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.

Command Default The default debugging level is 1.

Related Commands Command Description

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.

Firepower Management Center Configuration Guide, Version 6.3

926
 Firepower Threat Defense VPN
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.

Command Default The default debugging level is 1.

Related Commands Command Description

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.

Firepower Management Center Configuration Guide, Version 6.3

927
 Firepower Threat Defense VPN
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.

Command Default The default debugging level is 1.

Related Commands Command Description

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.

1-255 (Optional) Specifies the debugging level.

Command Default The default debugging level is 1.

Related Commands Command Description

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]

Firepower Management Center Configuration Guide, Version 6.3

928
 Firepower Threat Defense VPN
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.

Command Default The default debugging level is 1.

Related Commands Command Description

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.

1-255 (Optional) Specifies the debugging level.

Command Default The default debugging level is 1.

Related Commands Command Description

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.

Firepower Management Center Configuration Guide, Version 6.3

929
 Firepower Threat Defense VPN
debug ssl

1-255 (Optional) Specifies the debugging level.

Command Default The default debugging level is 1.

Related Commands Command Description

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.

1-255 (Optional) Specifies the debugging level.

Command Default The default debugging level is 1.

Related Commands Command Description

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.

Firepower Management Center Configuration Guide, Version 6.3

930
Firepower Threat Defense VPN
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.

Firepower Management Center Configuration Guide, Version 6.3

931
 Firepower Threat Defense VPN
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.

Command Default The default debugging level is 1.

Related Commands Command Description

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.

Firepower Management Center Configuration Guide, Version 6.3

932
PA R T XIII
Firepower Threat Defense Advanced Settings
• Threat Defense Service Policies, on page 935
• FlexConfig Policies for Firepower Threat Defense, on page 953
 CHAPTER 47
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 935
• Guidelines and Limitations for Service Policies, on page 937
• Configure Firepower Threat Defense Service Policies, on page 938
• Examples for Service Policy Rules, on page 946
• Monitoring Service Policies, on page 951
• History for Firepower Threat Defense Service Policy, on page 951

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.

Firepower Management Center Configuration Guide, Version 6.3

935
 Firepower Threat Defense Advanced Settings
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

Firepower Management Center Configuration Guide, Version 6.3

936
 Firepower Threat Defense Advanced Settings
Guidelines and Limitations 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.
• 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.

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
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.

Firepower Management Center Configuration Guide, Version 6.3

937
 Firepower Threat Defense Advanced Settings
Configure Firepower Threat Defense Service Policies

Configure Firepower Threat Defense Service Policies

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 the edit icon ( ) for the access control policy
whose Firepower Threat Defense Service Policy you want to edit.
Step 2 Click the Advanced tab.
Step 3 Click the edit icon ( ) 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.

Step 4 Do any of the following:

• Click Add Rule to create a new rule. See Configure a Service Policy Rule, on page 938.

• Click the edit icon ( ) to edit an existing rule. See Configure a Service Policy Rule, on page 938.

• Click the delete icon ( ) 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 the Advanced tab window. The changes are not saved until you click this button.

Configure a Service Policy Rule

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

Firepower Management Center Configuration Guide, Version 6.3

938
Firepower Threat Defense Advanced Settings
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 the Advanced tab, then edit the Threat
Defense Service Policy.
Step 2 Do any of the following:
• Click Add Rule to create a new rule.

• Click the edit icon ( ) 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 selected
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 Next 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 941.
Note Use TCP State Bypass for troubleshooting purposes or when asymmetric routing cannot be
resolved. This feature disables multiple security features, which can cause a high number of
connections if you do not implement it properly with a narrowly-defined traffic class.

• Randomize TCP Sequence Number (TCP connections only)—Whether to enable or disable TCP
sequence number randomization. Randomization is enabled by default. For more information, see Disable
TCP Sequence Randomization, on page 945.

Firepower Management Center Configuration Guide, Version 6.3

939
 Firepower Threat Defense Advanced Settings
Configure a Service Policy Rule

• 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 949.

• 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 946.

• 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 946.

• Connections Timeout—The timeout settings to apply to the traffic class. These timeouts override the
global timeouts defined in the platform settings policy. You can configure the following:
• Embryonic (TCP connections only)—The timeout period until a TCP embryonic (half-open)
connection is closed, between 0:0:5 and 1193:00:00. The default is 0:0:30.
• Half Closed (TCP connections only)—The idle timeout period until a half-closed connection is
closed, between 0:0:30 and 1193:0:0. The default is 0:10:0. Half-closed connections are not affected
by Dead Connection Detection (DCD). Also, the system does not send a reset when taking down
half-closed connections.

Firepower Management Center Configuration Guide, Version 6.3

940
 Firepower Threat Defense Advanced Settings
Bypass TCP State Checks for Asynchronous Routing (TCP State Bypass)

• 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
use DCD in a cluster.
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.
• 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.

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.

Firepower Management Center Configuration Guide, Version 6.3

941
 Firepower Threat Defense Advanced Settings
Guidelines and Limitations for TCP State Bypass

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 23: 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.

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.

Firepower Management Center Configuration Guide, Version 6.3

942
 Firepower Threat Defense Advanced Settings
Configure TCP State Bypass

• 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

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 the Add Extended Access List button.
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 the Port tab, select TCP (6) beneath the Selected Source Ports list, and click Add. Do not enter
a port number, simply add TCP as the protocol, which will cover all ports.
i) Click Add on the Extended Access List Entry dialog box to add the rule to the ACL.
j) Click Save on the Extended Access List Object dialog box to save the ACL object.
Step 2 Configure the TCP state bypass service policy rule.
For example, to configure TCP state bypass for this traffic class globally, do the following:
a) Choose Policies > Access Control > Access Control, and edit the policy assigned to the devices that
require this service.
b) Click the Advanced tab, and click the edit icon ( ) for the Threat Defense Service Policy.
c) Click Add Rule.

Firepower Management Center Configuration Guide, Version 6.3

943
 Firepower Threat Defense Advanced Settings
Configure TCP State Bypass

d) Select Apply Globally and click 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 the Advanced tab 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 icon ( ). This action opens a new browser window or
tab 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 tab—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 tab—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 tab—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.

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.

Firepower Management Center Configuration Guide, Version 6.3

944
 Firepower Threat Defense Advanced Settings
Disable TCP Sequence Randomization

You can now deploy the changes to the affected devices.

Disable TCP Sequence Randomization

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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:
a) Choose Objects > Object Management.
b) Choose Access List > Extended from the table of contents.
c) Click the Add Extended Access List button.
d) Enter a Name for the object, for example, preserve-sq-no.
e) Click Add to add a rule.
f) Keep Allow for the action.
g) Leave the Source list empty, enter 10.2.2.2 beneath the Destination list, and click Add.
h) Click the Port tab, select TCP (6) beneath the Selected Source Ports list, and click Add. Do not enter
a port number, simply add TCP as the protocol, which will cover all ports.
i) Click Add on the Extended Access List Entry dialog box to add the rule to the ACL.
j) Click Save on the Extended Access List Object dialog box to save the ACL object.

Firepower Management Center Configuration Guide, Version 6.3

945
 Firepower Threat Defense Advanced Settings
Examples for Service Policy Rules

Step 2 Configure the service policy rule that disables TCP sequence number randomization.
For example, to disable randomization for this traffic class globally, do the following:
a) Choose Policies > Access Control > Access Control, and edit the policy assigned to the devices that
require this service.
b) Click the Advanced tab, and click the edit icon ( ) for the Threat Defense Service Policy.
c) Click Add Rule.
d) Select Apply Globally and click Next.
e) Select the extended ACL object you created for this rule and click Next.
f) Deselect Randomize TCP Sequence Number.
g) (Optional.) Adjust the other connection options as needed.
h) Click Finish to add the rule. If necessary, drag and drop the rule to the desired position in the service
policy.
i) Click OK to save the changes to the service policy.
j) Click Save on the Advanced tab to save the changes to the access control policy.
You can now deploy the changes to the affected devices.

Examples for Service Policy Rules

The following topics provide examples of service policy rules.

Protect Servers from a SYN Flood DoS Attack (TCP Intercept)

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

946
Firepower Threat Defense Advanced Settings
Protect Servers from a SYN Flood DoS Attack (TCP Intercept)

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.
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:
a) Choose Objects > Object Management.
b) Choose Access List > Extended from the table of contents.
c) Click the Add Extended Access List button.
d) Enter a Name for the object, for example, protected-servers.
e) Click Add to add a rule.
f) Keep Allow for the action.
g) Leave the Source list empty, enter 10.1.1.5 beneath the Destination list, and click Add.
h) Also enter 10.1.1.6 beneath the Destination list and click Add.
i) Click the Port tab, select HTTP in the available ports list, and click Add to Destination. If your server
also support HTTPS connections, also add that port.
j) Click Add on the Extended Access List Entry dialog box to add the rule to the ACL.
k) Click Save on the Extended Access List Object dialog box to save the ACL object.
Step 2 Configure the service policy rule that sets embryonic connection limits.
For example, to set the total concurrent embryonic limit to 1000 connections, and the per-client limit to 50
connections, do the following:
a) Choose Policies > Access Control > Access Control, and edit the policy assigned to the devices that
require this service.
b) Click the Advanced tab, and click the edit icon ( ) for the Threat Defense Service Policy.
c) Click Add Rule.
d) Select Apply Globally and click Next.
e) Select the extended ACL object you created for this rule and click Next.
f) 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.

Firepower Management Center Configuration Guide, Version 6.3

947
 Firepower Threat Defense Advanced Settings
Protect Servers from a SYN Flood DoS Attack (TCP Intercept)

j) Click OK to save the changes to the service policy.

k) Click Save on the Advanced tab to save the changes to the access control policy.
Step 3 (Optional.) Configure the rates for TCP Intercept statistics.
TCP Intercept uses the following options to determine the rate for collecting statistics. All options have default
values, so if these rates suit your needs, you can skip this step.
• Rate Interval—The size of the history monitoring window, between 1 and 1440 minutes. The default is
30 minutes. During this interval, the system samples the number of attacks 30 times.
• Burst Rate—The threshold for syslog message generation, between 25 and 2147483647. The default is
400 per second. When the burst rate is exceeded, the device generates syslog message 733104.
• Average Rate—The average rate threshold for syslog message generation, between 25 and 2147483647.
The default is 200 per second. When the average rate is exceeded, the device generates syslog message
733105.

If you want to adjust these options, do the following:

a) Choose Objects > Object Management.
b) Choose FlexConfig > Text Object.
c) Click the edit icon ( ) 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 the Override tab.
g) The object must have 3 entries, so click the Count button 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 ###

Firepower Management Center Configuration Guide, Version 6.3

948
 Firepower Threat Defense Advanced Settings
Make the Firepower Threat Defense Device Appear on Traceroutes

threat-detection statistics tcp-intercept rate-interval 30

burst-rate 400 average-rate 200

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

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

949
 Firepower Threat Defense Advanced Settings
Make the Firepower Threat Defense Device Appear on Traceroutes

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:
a) Choose Objects > Object Management.
b) Choose Access List > Extended from the table of contents.
c) Click the Add Extended Access List button.
d) Enter a Name for the object, for example, traceroute-enabled.
e) Click Add to add a rule to exclude OSPF.
f) Change the action to Block, click the Port tab, select OSPFIGP (89) as the protocol beneath the
Destination Ports list, and click Add to add the protocol to the selected list.
g) Click Add on the Extended Access List Entry dialog box to add the OSPF rule to the ACL.
h) Click Add to add a rule to include all other connections.
i) Keep Allow for the action, and leave both the Source and Destination lists empty.
j) Click Add on the Extended Access List Entry dialog box to add the rule to the ACL.
Ensure that the OSPF deny rule is above the Allow Any rule. Drag and drop to move the rules if
necessary.
k) Click Save on the Extended Access List Object dialog box to save the ACL object.
Step 2 Configure the service policy rule that decrements the time-to-live value.
For example, to decrement time-to-live globally, do the following:
a) Choose Policies > Access Control > Access Control, and edit the policy assigned to the devices that
require this service.
b) Click the Advanced tab, and click the edit icon ( ) for the Threat Defense Service Policy.
c) Click Add Rule.
d) Select Apply Globally and click Next.
e) Select the extended ACL object you created for this rule and click Next.
f) Select Enable Decrement TTL.
g) (Optional.) Adjust the other connection options as needed.
h) Click Finish to add the rule. If necessary, drag and drop the rule to the desired position in the service
policy.
i) Click OK to save the changes to the service policy.
j) Click Save on the Advanced tab to save the changes to the access control policy.
You can now deploy the changes to the affected devices.

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.

Firepower Management Center Configuration Guide, Version 6.3

950
 Firepower Threat Defense Advanced Settings
Monitoring Service Policies

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

History for Firepower Threat Defense Service Policy

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.
Supported platforms: Firepower Threat Defense

Firepower Management Center Configuration Guide, Version 6.3

951
 Firepower Threat Defense Advanced Settings
History for Firepower Threat Defense Service Policy

Firepower Management Center Configuration Guide, Version 6.3

952
 CHAPTER 48
FlexConfig Policies for Firepower Threat Defense
The following topics describe how to configure and deploy FlexConfig policies.
• FlexConfig Policy Overview, on page 953
• Guidelines and Limitations for FlexConfig, on page 972
• Customizing Device Configuration with FlexConfig Policies, on page 973

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 blacklisted. 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.

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

Firepower Management Center Configuration Guide, Version 6.3

953
 Firepower Threat Defense Advanced Settings
CLI Commands in FlexConfig Objects

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
athttp://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.

Determine the ASA Software Version and Current CLI Configuration

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin

Defense
Firepower Threat
Defense Virtual

Firepower Management Center Configuration Guide, Version 6.3

954
 Firepower Threat Defense Advanced Settings
Blacklisted CLI Commands

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 1 Choose System > Health > Monitor.

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.

Blacklisted 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 blacklisted command areas.
In addition, some clear commands are blacklisted 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 blacklisted commands in the object.

Blacklisted CLI Command Description

AAA Configuration blocked.

Firepower Management Center Configuration Guide, Version 6.3

955
 Firepower Threat Defense Advanced Settings
Blacklisted CLI Commands

Blacklisted CLI Command Description

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.

pager Configuration blocked.

Firepower Management Center Configuration Guide, Version 6.3

956
 Firepower Threat Defense Advanced Settings
Template Scripts

Blacklisted CLI Command Description

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:
• Policy object variables are replaced with strings obtained from objects defined in Firepower Management
Center.

Firepower Management Center Configuration Guide, Version 6.3

957
 Firepower Threat Defense Advanced Settings
How to Process Variables

• 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")
sysopt connection tcpmss minimum $tcpMssBytes
#else
sysopt connection tcpmss $tcpMssBytes

Firepower Management Center Configuration Guide, Version 6.3

958
 Firepower Threat Defense Advanced Settings
Multiple Value Variables, All Values Are the Same Type

#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.

Firepower Management Center Configuration Guide, Version 6.3

959
 Firepower Threat Defense Advanced Settings
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_ipv6_prefix_addresses=[], intf_subnet_mask_v4=255.255.255.0,
intf_ip_addr_v4=10.100.11.1, intf_ipv6_link_local_address=,
intf_logical_name=inside},

{intf_hardwarare_id=GigabitEthernet0/2, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=, intf_ip_addr_v4=,
intf_ipv6_link_local_address=, intf_logical_name=},

{intf_hardwarare_id=Management0/0, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=, intf_ip_addr_v4=,
intf_ipv6_link_local_address=, intf_logical_name=diagnostic}]

In the above example, information is returned for 4 interfaces. Each interface includes a table of named values.
For example, intf_hardwarare_id is the name of the interface hardware name property, and returns strings
such as GigabitEthernet0/0.
This type of variable is typically of indeterminate length, so you need to use looping to process the values.
But you also need to add the property name to the variable name to indicate which value to retrieve.
For example, IS-IS configuration requires that you add the ASA isis command to an interface that has a logical
name in interface configuration mode. However, you enter that mode using the interface’s hardware name.
Thus, you need to identify which interfaces have logical names, then configure just those interfaces using
their hardware names. The ISIS_Interface_Configuration predefined FlexConfig does this using an if/then

Firepower Management Center Configuration Guide, Version 6.3

960
 Firepower Threat Defense Advanced Settings
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 ###

Firepower Management Center Configuration Guide, Version 6.3

961
 Firepower Threat Defense Advanced Settings
FlexConfig Policy Object Variables

###CLI generated from managed features ###

###Flex-config Appended CLI ###

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_ipv6_prefix_addresses=[], intf_subnet_mask_v4=255.255.255.0,
intf_ip_addr_v4=10.100.10.1, intf_ipv6_link_local_address=,
intf_logical_name=outside},

{intf_hardwarare_id=GigabitEthernet0/1, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=255.255.255.0,
intf_ip_addr_v4=10.100.11.1, intf_ipv6_link_local_address=,
intf_logical_name=inside},

{intf_hardwarare_id=GigabitEthernet0/2, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=, intf_ip_addr_v4=,
intf_ipv6_link_local_address=, intf_logical_name=},

{intf_hardwarare_id=Management0/0, intf_ipv6_eui64_addresses=[],
intf_ipv6_prefix_addresses=[], intf_subnet_mask_v4=, intf_ip_addr_v4=,
intf_ipv6_link_local_address=, intf_logical_name=diagnostic}]

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

Firepower Management Center Configuration Guide, Version 6.3

962
 Firepower Threat Defense Advanced Settings
FlexConfig System Variables

are highly flexible and built specifically for use within FlexConfig objects. For detailed information, see
Configure FlexConfig Text Objects, on page 979.
• 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 371.
• 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 379.
• 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 439.
• 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 439.
• 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 436.

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 961.

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.

Firepower Management Center Configuration Guide, Version 6.3

963
 Firepower Threat Defense Advanced Settings
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.

Predefined FlexConfig Objects

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.

Firepower Management Center Configuration Guide, Version 6.3

964
 Firepower Threat Defense Advanced Settings
Predefined FlexConfig Objects

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.
Also uses the system variable
SYS_FTD_ROUTED_INTF_MAP_LIST

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
Also uses the system variable
SYS_FTD_ROUTED_INTF_MAP_LIST

Firepower Management Center Configuration Guide, Version 6.3

965
 Firepower Threat Defense Advanced Settings
Predefined FlexConfig Objects

FlexConfig Object Name Description Associated Text Objects

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

Also uses the system variable
SYS_FTD_ROUTED_INTF_MAP_LIST

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.

Firepower Management Center Configuration Guide, Version 6.3

966
 Firepower Threat Defense Advanced Settings
Predefined FlexConfig Objects

FlexConfig Object Name Description Associated Text Objects

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.
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.

Threat_Detection_Clear Clear the threat detection TCP Intercept —

configuration.

Firepower Management Center Configuration Guide, Version 6.3

967
 Firepower Threat Defense Advanced Settings
Predefined Text Objects

FlexConfig Object Name Description Associated 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. —

Predefined Text Objects

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 979.

Name Description Associated FlexConfig Object

defaultDNSNameServerList The DNS server IP address to configure in Default_DNS_Configure

the Default DNS group.
(Deprecated.)
Starting with version 6.3, configure DNS
for the data interfaces in the Firepower
Threat Defense Platform Settings policy.

Firepower Management Center Configuration Guide, Version 6.3

968
 Firepower Threat Defense Advanced Settings
Predefined Text Objects

Name Description Associated FlexConfig Object

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.
Starting with version 6.3, configure DNS
for the data interfaces in the Firepower
Threat Defense Platform Settings policy.

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.

Firepower Management Center Configuration Guide, Version 6.3

969
 Firepower Threat Defense Advanced Settings
Predefined Text Objects

Name Description Associated FlexConfig Object

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.

Firepower Management Center Configuration Guide, Version 6.3

970
 Firepower Threat Defense Advanced Settings
Predefined Text Objects

Name Description Associated FlexConfig Object

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.)
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_conn_misc Parameters used for configuring the TCP TCP_Embryonic_Conn_Limit,

embryonic connection settings. TCP_Embryonic_Conn_Timeout
(Deprecated.)
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_conn_timeout Parameters used for configuring the TCP TCP_Embryonic_Conn_Timeout

embryonic connection timeouts.
(Deprecated.)
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.

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.

Firepower Management Center Configuration Guide, Version 6.3

971
 Firepower Threat Defense Advanced Settings
Guidelines and Limitations for FlexConfig

Name Description Associated FlexConfig Object

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

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

Firepower Management Center Configuration Guide, Version 6.3

972
 Firepower Threat Defense Advanced Settings
Customizing Device Configuration with FlexConfig Policies

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

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin

Defense
Firepower Threat
Defense Virtual

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.

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 953

Firepower Management Center Configuration Guide, Version 6.3

973
 Firepower Threat Defense Advanced Settings
Customizing Device Configuration with FlexConfig Policies

• CLI Commands in FlexConfig Objects, on page 954

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 the view icon ( ) 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 964.
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 957
• FlexConfig Policy Object Variables, on page 962
• FlexConfig System Variables, on page 963
• Configure FlexConfig Text Objects, on page 979

Step 4 If you are using the predefined FlexConfig objects, edit the text objects used as variables.
See Configure FlexConfig Text Objects, on page 979.

Step 5 (If necessary.) Configure FlexConfig Objects, on page 975.

You need to create objects only if the predefined objects cannot do the job.

Step 6 Configure the FlexConfig Policy, on page 981.

Step 7 Set Target Devices for a FlexConfig Policy, on page 982.
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 983.

Firepower Management Center Configuration Guide, Version 6.3

974
 Firepower Threat Defense Advanced Settings
Configure FlexConfig Objects

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 Click Deploy in the menu bar, select the devices assigned to the policy, and click the Deploy button.
Wait for deployment to complete.

Step 10 Verify the Deployed Configuration, on page 984.

Step 11 (If necessary.) Remove Features Configured Using FlexConfig, on page 986.
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.

Configure FlexConfig Objects

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin

Defense
Firepower Threat
Defense Virtual

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

Firepower Management Center Configuration Guide, Version 6.3

975
 Firepower Threat Defense Advanced Settings
Configure FlexConfig Objects

Procedure

Step 1 Choose Objects > Object Management.

Step 2 Choose FlexConfig > FlexConfig Object from the list of object types.
Step 3 Do one of the following:
• Click Add FlexConfig Object to create a new object.

• Click the edit icon ( ) to edit an existing object.

• Click the view icon ( ) to see the contents of a predefined object.

• If you want to edit a predefined object, click the copy icon ( ) 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 957
• CLI Commands in FlexConfig Objects, on page 954

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 957.
• To insert system variables, choose Insert > Insert System Variable > Variable Name. For a detailed
explanation of these variables, see FlexConfig System Variables, on page 963.
• 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 962. For more detail on the procedure,
see Add a Policy Object Variable to a FlexConfig Object, on page 978.
• 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 978.

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.

Firepower Management Center Configuration Guide, Version 6.3

976
Firepower Threat Defense Advanced Settings
Configure FlexConfig Objects

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
983. 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 984). 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 the Validate icon 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.

Step 8 Click Save.

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

Firepower Management Center Configuration Guide, Version 6.3

977
 Firepower Threat Defense Advanced Settings
Add a Policy Object Variable to a FlexConfig Object

Add a Policy Object Variable to a FlexConfig Object

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin

Defense
Firepower Threat
Defense Virtual

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 958.

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

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin

Defense
Firepower Threat
Defense Virtual

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.

Firepower Management Center Configuration Guide, Version 6.3

978
 Firepower Threat Defense Advanced Settings
Configure FlexConfig Text Objects

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 958.

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 the edit icon ( ) for the variable. Make your changes
and click Add.

• To delete a secret key variable, click the delete icon ( ) for the variable.

Step 3 Click Save.

Configure FlexConfig Text Objects

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin

Defense
Firepower Threat
Defense Virtual

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.

Firepower Management Center Configuration Guide, Version 6.3

979
 Firepower Threat Defense Advanced Settings
Configure FlexConfig Text Objects

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 957
• How to Process Variables, on page 958

Procedure

Step 1 Choose Objects > Object Management.

Step 2 Choose FlexConfig > Text Object from the list of object types.
Step 3 Do one of the following:
• Click Add Text Object to create a new object.

• Click the edit icon ( ) 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 the edit icon for the override to change it.

Firepower Management Center Configuration Guide, Version 6.3

980
 Firepower Threat Defense Advanced Settings
Configure the FlexConfig Policy

c) On the Targets tab 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 the Override tab, 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
• If an active policy references your object, deploy configuration changes; see Deploy Configuration
Changes, on page 308.

Configure the FlexConfig Policy

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin

Defense
Firepower Threat
Defense Virtual

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 975.
FlexConfig policies are shared policies that you can assign to multiple devices.

Procedure

Step 1 Choose Devices > FlexConfig.

Step 2 Do one of the following:
• 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 the edit icon ( ) to edit an existing Policy. You can change the name or description by clicking
them in edit mode.

• Click the copy icon ( ) to create a new policy with the same contents. You are prompted for a name.
Device assignments are not retained for the copy.
• Click the delete icon 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.

Firepower Management Center Configuration Guide, Version 6.3

981
 Firepower Threat Defense Advanced Settings
Set Target Devices for a FlexConfig Policy

To remove a selected object, click the delete icon ( ) next to an object.

Step 4 For each selected object, click the view icon ( ) 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 983.

Step 5 Click Save.

What to do next
• Set target devices for the policy; see Set Target Devices for a FlexConfig Policy, on page 982.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Set Target Devices for a FlexConfig Policy

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin

Defense
Firepower Threat
Defense Virtual

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 986.

Procedure

Step 1 Choose Devices > FlexConfig and edit a FlexConfig policy.

Step 2 Click Policy Assignments.
Step 3 On the Targeted Devices tab, build your target list:

Firepower Management Center Configuration Guide, Version 6.3

982
 Firepower Threat Defense Advanced Settings
Preview the FlexConfig Policy

• 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 the delete icon ( ) 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
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Preview the FlexConfig Policy

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin

Defense
Firepower Threat
Defense Virtual

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.

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:

Firepower Management Center Configuration Guide, Version 6.3

983
 Firepower Threat Defense Advanced Settings
Verify the Deployed Configuration

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

Verify the Deployed Configuration

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin

Defense
Firepower Threat
Defense Virtual

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 the System Status icon in the menu bar, which is the unnamed icon 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 or errors are present on the system.

• — Indicates one or more warnings and no errors are present on the system.

• — Indicates one or more errors and any number of warnings are present on the system.

b) On the Deployments tab, verify that the deployment was successful.

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 the download icon 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.

Firepower Management Center Configuration Guide, Version 6.3

984
Firepower Threat Defense Advanced Settings
Verify the Deployed Configuration

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 =========

FMC >> interface GigabitEthernet0/0

FMC >> nameif outside
FTDv 192.168.0.152 >> [info] : INFO: Security level for "outside" set to 0 by default.

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 the Threat Defense CLI tab.
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.
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 Management Center Configuration Guide, Version 6.3

985
 Firepower Threat Defense Advanced Settings
Remove Features Configured Using FlexConfig

firepower> enable
Password: <press enter, do not enter a password>
firepower#

Remove Features Configured Using FlexConfig

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin

Defense
Firepower Threat
Defense Virtual

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 983. 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

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.

Firepower Management Center Configuration Guide, Version 6.3

986
Firepower Threat Defense Advanced Settings
Remove Features Configured Using FlexConfig

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 Click Deploy in the menu bar, select the device, and click the Deploy button.
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 984.

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.

Firepower Management Center Configuration Guide, Version 6.3

987
 Firepower Threat Defense Advanced Settings
Remove Features Configured Using FlexConfig

Firepower Management Center Configuration Guide, Version 6.3

988
PA R T XIV
Appliance Platform Settings
• System Configuration, on page 991
• Platform Settings Policies for Managed Devices, on page 1065
• Platform Settings for Classic Devices, on page 1069
• Platform Settings for Firepower Threat Defense, on page 1091
• Security Certifications Compliance, on page 1135
 CHAPTER 49
System Configuration
The following topics explain how to configure system configuration settings on Firepower Management
Centers and managed devices:
• Introduction to System Configuration, on page 992
• Appliance Information, on page 995
• HTTPS Certificates, on page 997
• External Database Access Settings, on page 1002
• Database Event Limits, on page 1004
• Management Interfaces, on page 1006
• System Shut Down and Restart, on page 1022
• Remote Storage Management, on page 1024
• Change Reconciliation, on page 1027
• Policy Change Comments, on page 1029
• The Access List, on page 1030
• Audit Logs, on page 1031
• Audit Log Certificate , on page 1034
• Dashboard Settings, on page 1040
• DNS Cache, on page 1040
• Email Notifications, on page 1041
• Language Selection, on page 1042
• Login Banners, on page 1043
• SNMP Polling, on page 1044
• Time and Time Synchronization, on page 1046
• Global User Configuration Settings, on page 1050
• Session Timeouts, on page 1052
• Vulnerability Mapping, on page 1053
• Remote Console Access Management, on page 1054
• REST API Preferences, on page 1061
• VMware Tools and Virtual Systems, on page 1061
• (Optional) Opt Out of Web Analytics Tracking, on page 1062
• History for System Configuration, on page 1063

Firepower Management Center Configuration Guide, Version 6.3

991
 Appliance Platform Settings
Introduction to System Configuration

Introduction to System Configuration

System configuration settings apply to either a Firepower Management Center or a Classic managed device
(7000 and 8000 Series, 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.

Tip For 7000 and 8000 Series devices, you can perform limited system configuration
tasks from the local web interface, such as console configuration and remote
management. These are not the same configurations that you apply to a 7000 or
8000 Series device using a platform settings policy.

Navigating the Firepower Management Center System Configuration

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

The system configuration identifies basic settings for a Firepower Management Center.

Procedure

Step 1 Choose System > Configuration.

Step 2 Use the navigation panel to choose configurations to change; see Table 73: System Configuration Settings ,
on page 993 for more information.

System Configuration Settings

The following table describes the system configuration settings for the Firepower Management Center. For
7000 and 8000 Series devices, the table also identifies which settings you configure from the device's local
web interface, and which you configure using a platform settings policy deployed from the Firepower
Management Center.

Firepower Management Center Configuration Guide, Version 6.3

992
 Appliance Platform Settings
System Configuration Settings

Table 73: System Configuration Settings

Setting Description Also configurable from:

Platform 7000 & 8000

Settings Series

Information View current information about the appliance and edit the display name; see no yes
Appliance Information, on page 995.

HTTPS Certificate Request an HTTPS server certificate, if needed, from a trusted authority and no yes
upload certificates to the system; see HTTPS Certificates, on page 997 .

External Database Enable external read-only access to the database, and provide a client driver to no no
Access download; see External Database Access Settings, on page 1002.

Database Specify the maximum number of each type of event that the Firepower no no
Management Center can store; see Database Event Limits, on page 1004.

Management Change options such as the IP address, hostname, and proxy settings of the no yes
Interfaces appliance; see Management Interfaces, on page 1006.

Process Shut down, reboot, or restart Firepower System-related processes; see System no yes
Shut Down and Restart, on page 1022.

Remote Storage Configure remote storage for backups and reports; see Remote Storage no no
Device Management, on page 1024.

Change Configure the system to send a detailed report of changes to the system over the no yes
Reconciliation last 24 hours; see Change Reconciliation, on page 1027.

Access Control Configure the system to prompt users for a comment when they add or modify no no
Preferences an access control policy; see Policy Change Comments, on page 1029.

Access List Control which computers can access the system on specific ports; see The Access yes no
List, on page 1030.

Audit Log Configure the system to send an audit log to an external host; see Audit Logs, yes no
on page 1031.

Audit Log Client Configure the system to secure the channel when streaming the audit log to an yes yes
Certificates external host; see Audit Log Certificate , on page 1034

Dashboard Enable Custom Analysis widgets on the dashboard; see Dashboard Settings, on no no
page 1040.

DNS Cache Configure the system to resolve IP addresses automatically on event view pages; no no
see DNS Cache, on page 1040.

Email Notification Configure a mail host, select an encryption method, and supply authentication no no
credentials for email-based notifications and reporting; see Email Notifications,
on page 1041.

Firepower Management Center Configuration Guide, Version 6.3

993
 Appliance Platform Settings
System Configuration Settings

Setting Description Also configurable from:

Platform 7000 & 8000

Settings Series

External Set the default user role for any user who is authenticated by an external RADIUS, yes no
Authentication LDAP or Microsoft Active Directory repository; see External Authentication
Settings, on page 1080

Intrusion Policy Configure the system to prompt users for a comment when they modify an no no
Preferences intrusion policy; see Policy Change Comments, on page 1029.

Language Specify a different language for the web interface; see Language Selection, on yes no
page 1042.

Login Banner Create a custom login banner that appears when users log in; see Login Banners, yes no
on page 1043.

Network Analysis Configure the system to prompt users for a comment when they modify a network no no
Policy Preferences analysis policy; see Policy Change Comments, on page 1029.

SNMP Enable Simple Network Management Protocol (SNMP) polling; see SNMP yes no
Polling, on page 1044.

UCAPL/CC Enable compliance with specific requirements set out by the United States yes no
Compliance Department of Defense; see Enabling Security Certifications Compliance, on
page 1140.

Time View the current time setting and, if the time synchronization setting in the current no yes
system configuration is set to Manually in Local Configuration, change the
time; see Time and Time Synchronization, on page 1046.

Time Manage time synchronization on the system; see Time and Time Synchronization, yes no
Synchronization on page 1046.

User Configuration Configure the Firepower Management Center to track successful login history no no
and password history for all users, or enforce temporary lockouts on users who
enter invalid login credentials; see Global User Configuration Settings, on page
1050

Shell Timeout Configure the amount of idle time, in minutes, before a user’s login session times yes no
out due to inactivity; see Session Timeouts, on page 1052.

Vulnerability Map vulnerabilities to a host IP address for any application protocol traffic no no
Mapping received or sent from that address; see Vulnerability Mapping, on page 1053.

Console Configure console access via VGA or serial port, or via Lights-Out Management no limited
Configuration (LOM); see Remote Console Access Management, on page 1054.

Console Enable or disable the Firepower Management Center CLI; see the Firepower no no
Configuration Management Center Command Line Reference, on page 2753

REST API Enable or disable access to the Firepower Management Center via the Firepower no no
Preferences REST API; see REST API Preferences, on page 1061.

Firepower Management Center Configuration Guide, Version 6.3

994
 Appliance Platform Settings
Appliance Information

Setting Description Also configurable from:

Platform 7000 & 8000

Settings Series

VMware Tools Enable and use VMware Tools on a Firepower Management Center Virtual; see n/a n/a
VMware Tools and Virtual Systems, on page 1061.

Web Analytics Enable and disable collection of non-personally-identifiable information from no no

your system. See (Optional) Opt Out of Web Analytics Tracking, on page 1062.

Related Topics
Introduction to Firepower Platform Settings, on page 1069

Appliance Information
The Information page of the web interface includes the information listed in the table below. Unless otherwise
noted, all fields are read-only.

Field Description

Name A name you assign to the appliance. Note that this

name is only used within the context of the Firepower
System. 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.

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.

Prohibit Packet Transfer to the Firepower Specifies whether the managed device sends packet
Management Center data with events, allowing the data to be stored on the
Firepower Management Center. This setting is
available on the local web interface on 7000 and 8000
Series devices.

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.

Firepower Management Center Configuration Guide, Version 6.3

995
 Appliance Platform Settings
Viewing and Modifying the System Information

Field Description

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.

Viewing and Modifying the System Information

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

7000 & 8000 Series

The Information page on the Firepower Management Center’s web interface or on the 7000 and 8000 Series
local web interface provides information about your system, including read-only information such as the
product name and model number. The page also provides you with an option to change the display name of
the system and, for 7000 and 8000 Series devices, prohibit packet transfer.

Note Prohibiting packet transfer can be a good idea in a low-bandwidth deployment where you are not concerned
about the specific content of the packet that triggered the intrusion policy violation.

Procedure

Step 1 Choose System > Configuration.

Step 2 Optionally, change the system information settings:
• Name—To change the display name, enter a name in the Name field.
• Prohibit packet transfer—To prevent sending packet data to the Firepower Management Center, check
the Prohibit Packet Transfer to the Management Center check box. This option is only available
from a 7000 or 8000 Series device's local web interface.

Step 3 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

996
 Appliance Platform Settings
HTTPS Certificates

HTTPS Certificates
Secure Sockets Layer (SSL) certificates enable Firepower Management Centers and 7000 and 8000 Series
devices to establish an encrypted channel between the system and a web browser. A default certificate is
included with all Firepower devices, but it is not generated by a certificate authority (CA) trusted by any
globally known CA. For this reason, consider replacing it with a custom certificate signed by a globally known
or internally trusted CA.

Caution The 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.

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 default server certificate provided with an appliance automatically expires in three years. If your appliance
uses a default certificate that was generated before you upgraded to Version 6.3, the certificate will expire
twenty years from when it was first generated.
On the Firepower Management Center and 7000 and 8000 Series devices, you can renew the default certificate
on the System > Configuration > HTTPS Certificate page. On 7000 and 8000 Series devices, you can
also renew the default certificate with the CLI command system renew-http-cert.

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 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.

Firepower Management Center Configuration Guide, Version 6.3

997
 Appliance Platform Settings
Viewing the Current HTTPS 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

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

7000 and 8000
Series

You can only view server certificates for the appliance you are logged in to.

Procedure

Step 1 Choose System > Configuration.

Step 2 Click HTTPS Certificate.

Generating an HTTPS Server Certificate Signing Request

Smart License Classic License Supported Devices Supported Domains Access

N/A Any FMC Global only Admin

7000 and 8000
Series

When you generate a certificate request through the local configuration HTTPS Certificate page using this
procedure, you can only generate a certificate for a single system. If you install a certificate that is not signed
by a globally known or internally trusted CA, your browser displays a security warning when you try to
connect to the web interface.
The key generated for the certificate request is in Base-64 encoded PEM format.

Firepower Management Center Configuration Guide, Version 6.3

998
 Appliance Platform Settings
Importing HTTPS Server Certificates

Procedure

Step 1 Choose System > Configuration.

Step 2 Click HTTPS 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 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 Click Generate.

Step 11 Open 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 servername.csr, where servername is the name of the server where you plan to use the
certificate.
Step 14 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 999.

Importing HTTPS Server Certificates

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

7000 and 8000
Series

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:

Firepower Management Center Configuration Guide, Version 6.3

999
 Appliance Platform Settings
Importing HTTPS Server Certificates

• 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 998.
• 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.

Procedure

Step 1 Choose System > Configuration.

Step 2 Click HTTPS Certificate.
Step 3 Click Import HTTPS Server Certificate.
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 998), 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.

Firepower Management Center Configuration Guide, Version 6.3

1000
 Appliance Platform Settings
Requiring Valid HTTPS Client Certificates

Requiring Valid HTTPS Client Certificates

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

7000 and 8000
Series

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 999.
• Import the server certificate chain if needed; see Importing HTTPS Server Certificates, on page 999.

Procedure

Step 1 Choose System > Configuration.

Step 2 Click HTTPS Certificate.
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.

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.)

Firepower Management Center Configuration Guide, Version 6.3

1001
 Appliance Platform Settings
Renewing the Default HTTPS Server Certificate

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 196

Renewing the Default HTTPS Server Certificate

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

7000 and 8000
Series

You can only view server certificates for the appliance you are logged in to.

Procedure

Step 1 Choose System > Configuration.

Step 2 Click HTTPS Certificate.
The button appears only if your system is configured to use the default HTTPS server certificate.

Step 3 Click Renew HTTPS Certificate button. (This button 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
• any other reporting application (including a custom application) that supports JDBC SSL connections

Firepower Management Center Configuration Guide, Version 6.3

1002
 Appliance Platform Settings
Enabling External Access to the Database

• 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

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

Procedure

Step 1 Choose System > Configuration.

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.
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 15

Firepower Management Center Configuration Guide, Version 6.3

1003
 Appliance Platform Settings
Database Event Limits

Database Event Limits

You can specify the maximum number of each type of event that the Firepower Management Center can store.
To improve performance, you should tailor event limits to the number of events you regularly work with. For
some event types, you can disable storage.
The system automatically prunes intrusion events, discovery events, audit records, security intelligence data,
or URL filtering data from the appliance's database. You can configure the system to generate automated
email notifications when events are automatically pruned. You can also manually prune the discovery and
user databases to remove selected discovery data; and you can purge discovery and connection data from the
Firepower Management Center database.

Configuring Database Event Limits

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

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
Address, on page 1041.

Procedure

Step 1 Choose System > Configuration.

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 1004.

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.

Database Event Limits

The following table lists the minimum and maximum number of records for each event type that you can store
on a Firepower Management Center.

Firepower Management Center Configuration Guide, Version 6.3

1004
Appliance Platform Settings
Database Event Limits

Table 74: Database Event Limits

Event Type Upper Limit Lower Limit

Intrusion events 10 million (FMC Virtual) 10,000

20 million (MC750)
30 million (MC1000, MC1500)
60 million (MC2000, MC2500)
150 million (MC3500)
300 million (MC4000, MC4500)

Discovery events 10 million Zero (disables storage)

20 million (MC2000, MC2500, MC4000,
MC4500)

Connection events 50 million (FMC Virtual) Zero (disables storage)

Security Intelligence events 50 million (MC750)
100 million (MC1000, MC1500)
300 million (MC2000, MC2500)
500 million (MC3500)
1 billion (MC4000, MC4500)
Limit is shared between connection events and
Security Intelligence events. The sum of the
configured maximums cannot exceed this limit.

Connection summaries (aggregated 50 million (FMC Virtual) Zero (disables storage)

connection events)
50 million (MC750)
100 million (MC1000, MC1500)
300 million (MC2000, MC2500)
500 million (MC3500)
1 billion (MC4000, MC4500)

Correlation events and compliance 1 million One

white list events
2 million (MC2000, MC2500 , MC4000,
MC4500)

Malware events 10 million 10,000

20 million (MC2000, MC2500 , MC4000,
MC4500)

File events 10 million Zero (disables storage)

20 million (MC2000, MC2500 MC4000,
MC4500)

Firepower Management Center Configuration Guide, Version 6.3

1005
 Appliance Platform Settings
Management Interfaces

Event Type Upper Limit Lower Limit

Health events 1 million Zero (disables storage)

Audit records 100,000 One

Remediation status events 10 million One

White 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)

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 both the FMC and the managed devices.

About Management Interfaces

By default, the Firepower Management Center manages all devices on a single management interface. Each
device includes a single management interface for communicating with the FMC.
You also perform initial setup on the management interface (for both the FMC and managed devices), and
log into the FMC on this interface as an administrator.
Management interfaces are also used to communicate with the Smart Licensing server, to download updates,
and to perform other management functions.

Management Interfaces on the Firepower Management Center

The Firepower Management Center 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

Firepower Management Center Configuration Guide, Version 6.3

1006
 Appliance Platform Settings
Management Interfaces on Managed Devices

interface, if available, while using 1 GigabitEthernet interfaces for management. You might want to configure
an event-only interface on a completely secure, private network while using the regular management interface
on a network that includes Internet access, for example. You can also use both management and event interfaces
on the same network if the goal is only to take advantage of increased throughput. If you configure an event-only
interface on the FMC, you can support devices with separate management and event-only interfaces, but also
devices that do not have separate interfaces. For devices with a single combined management/event interface,
all traffic goes to the FMC management interface.

Note All management interfaces support HTTP administrator access as controlled by your Access List configuration
(Configuring the Access List for Your System, on page 1030). 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.

Management Interfaces on Managed Devices

Some models include an additional management interface that you can configure for event-only traffic, so
you can separate management and event traffic when communicating with the FMC.
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 both the device and the FMC have separate event interfaces, then after they learn about each other's event
interfaces during management communication, subsequent event traffic is sent between these interfaces if the
network allows. If the event network goes down, then event traffic reverts to the regular management interface.
The device uses a separate event interface when possible, but the management interface is always the backup.
If you use only one management interface on the managed device, then you cannot send management traffic
to the FMC management interface, and then send event traffic to the separate FMC event interface; both FMC
and managed device must have separate event interfaces. In this case, both management and event traffic go
to the FMC management interface, and the FMC event interface is not used for this device.

Management Interface Support

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.

Firepower Management Center Configuration Guide, Version 6.3

1007
 Appliance Platform Settings
Management Interface Support

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 631
for more information.

See the following tables for supported management interfaces on each Firepower Management Center and
managed device model.

Table 75: Management Interface Support on the Firepower Management Center

Model Management Interfaces

MC750, MC1500, MC3500 eth0 (Default)

eth1

MC2000, MC4000 eth0 (Default)

eth1
eth2
eth3

MC1000 eth0 (Default)

eth1

MC2500, MC4500 eth0 (Default)

eth1
eth2
eth3

Firepower Management Center Virtual eth0 (Default)

Table 76: Management Interface Support on Managed Devices

Model Management Interface Optional Event Interface

7000 series eth0 No support

8000 series eth0 eth1

NGIPSv eth0 No support

ASA FirePOWER services module eth0 eth1

on the ASA 5585-X
Note eth0 is the internal name Note eth1 is the internal name
of the Management 1/0 of the Management 1/1
interface. interface.

Firepower Management Center Configuration Guide, Version 6.3

1008
Appliance Platform Settings
Management Interface Support

Model Management Interface Optional Event Interface

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 ASA 5525-X through
Note eth0 is the internal name
5555-X
of the Management 0/0
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
of the Management 1/1
interface.

Firepower Threat Defense on the br1 No support

5525 through 5555-X
Note br1 is the internal name
of the Management 0/0
interface.

Firepower Threat Defense on the br1 No support

ISA 3000
Note br1 is the internal name
of the Management 1/1
interface.

Firepower Threat Defense Virtual br1 No support

Firepower Management Center Configuration Guide, Version 6.3

1009
 Appliance Platform Settings
Network Routes on Management Interfaces

Network Routes on Management Interfaces

Management interfaces (including event-only interfaces) support only static routes to reach remote networks.
When you set up your FMC or 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.
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 1 static route is recommended per management interface to access remote networks, including when
multiple interfaces are on the same network.
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 2 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
a static route through the event-only interface for traffic destined for the remote event-only network, and vice
versa.

Note The routing for management interfaces is completely separate from routing that you configure for data
interfaces.

Management and Event Traffic Channel Examples

The following example shows the Firepower Management Center and managed devices using only the default
management interfaces.
Figure 24: 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.

Firepower Management Center Configuration Guide, Version 6.3

1010
 Appliance Platform Settings
Configure Management Interfaces

Figure 25: 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 26: 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 27: Mixed Management and Event Interface Usage

Configure Management Interfaces

You can change management interface settings for Firepower appliances:
• Firepower Management Center—Use the web interface. (The Firepower Management Center supports
Linux shell access only under Cisco TAC supervision.)
• FTD devices, NGIPSv, ASA FirePOWER—Use the CLI
• 7000 & 8000 Series devices—Use the limited web interface or the CLI.

Firepower Management Center Configuration Guide, Version 6.3

1011
 Appliance Platform Settings
Configure Firepower Management Center Management Interfaces

See the following sections.

Related Topics
Communication Port Requirements, on page 2681

Configure Firepower Management Center Management Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

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.

Before you begin

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

Firepower Management Center Configuration Guide, Version 6.3

1012
Appliance Platform Settings
Configure Firepower Management Center Management Interfaces

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.

Step 3 In the Routes area, edit a static route by clicking the edit icon ( ), or add a route by clicking the add icon
( ). View the route statistics by clicking the view icon ( ).
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 Management Interfaces, on page 1010.
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.

You can configure the following shared settings:

• Hostname—Set the FMC hostname. 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
management interface.

Firepower Management Center Configuration Guide, Version 6.3

1013
 Appliance Platform Settings
Configure Classic Device Management Interfaces at the Web Interface

• 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 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 6 Click Save.
Step 7 If you changed the management IP address, it might affect communication between the FMC and managed
devices.
Changing the IP address will not affect the current connection. However, if the device or FMC reloads, then
the connection needs to be reestablished. You need at least one of the devices (FMC or managed device) to
have the correct IP address of the peer. For example, if you added the device on the FMC and specified a
NAT ID (instead of an IP address), then the FMC IP address that you defined on the device at setup will be
wrong, and the device will not be able to reestablish communications. Moreover, you cannot update the FMC
IP address on a device; you can only replace the IP address and re-register as a new device (configure manager
add). On the other hand, if the FMC knows the correct IP address of the managed device, then even if the
managed device has the wrong IP address for the FMC, then the FMC can successfully establish the connection.

Configure Classic Device Management Interfaces at the Web Interface

Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 & 8000 Series Global only Admin

Modify the management interface settings on the managed device using the web interface. You can optionally
enable an event interface if your model supports it.

Firepower Management Center Configuration Guide, Version 6.3

1014
Appliance Platform Settings
Configure Classic Device Management Interfaces at the Web Interface

Caution 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 and reconfigure the settings at the CLI.

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—(8000 series only) Configure an event-only interface. You can enable the eth1 management
interface on your 8000 series device to act as an event interface. To do so, uncheck the Management
Traffic check box, and leave the Event Traffic check box checked. For the eth0 management interface,
leave both check boxes checked.
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 Event Traffic for the management interface. 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.
• Mode—Specify a link mode. Note that any changes you make to auto-negotiation are ignored for
GigabitEthernet interfaces.
• 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.
• MDI/MDIX—Set the Auto-MDIX setting.
• 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).

Firepower Management Center Configuration Guide, Version 6.3

1015
 Appliance Platform Settings
Configure Classic Device Management Interfaces at the Web Interface

• Router Assigned—Enable stateless autoconfiguration.

• Disabled—Disable IPv6. Do not disable both IPv4 and IPv6.

Step 3 In the Routes area, edit a static route by clicking the edit icon ( ), or add a route by clicking the add icon
( ). View the route statistics by clicking the view icon ( ).
Note You need to 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. 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. For information
about routing, see Network Routes on Management Interfaces, on page 1010.

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.

You can configure the following shared settings:

• Hostname—Set the device hostname. If you change the hostname, reboot the device 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 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.
• 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 the FMC. 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 LCD Panel area, check the Allow reconfiguration of network settings check box to enable changing
network settings using the device’s LCD panel.

Firepower Management Center Configuration Guide, Version 6.3

1016
 Appliance Platform Settings
Configure Firepower Threat Defense or Classic Device Management Interfaces at the CLI

You can use the LCD panel to edit the IP address for the device. Confirm that any changes you make are
reflected on the managing Firepower Management Center. In some cases, you may need to update the data
manually on the Firepower Management Center as well.
Caution Allowing reconfiguration using the LCD panel can present a security risk. You need only physical
access, not authentication, to configure network settings using the LCD panel. The web interface
warns you that enabling this option is a potential security issue.

Step 6 In the Proxy area, configure HTTP proxy settings.

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.
Note Proxies that use NT LAN Manager (NTLM) authentication are not supported.

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.
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 changed the management IP address, it might affect communication between the FMC and the managed
device.
Changing the IP address will not affect the current connection. However, if the device or FMC reloads, then
the connection needs to be reestablished. You need at least one of the devices (FMC or managed device) to
have the correct IP address of the peer. For example, if you specified a NAT ID (instead of an IP address) for
the FMC during device setup, then the device IP address that you defined on the FMC when you added the
device will be wrong, and the FMC will not be able to reestablish communications. In this case, you must
change the management IP address of the device in the FMC; see Editing Device Management Settings, on
page 505.

Configure Firepower Threat Defense or Classic Device Management Interfaces at the CLI
Smart License Classic License Supported Devices Supported Domains Access

Any Any FTD Global only Admin

Classic

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. For
information about the FTD CLI, see Command Reference for Firepower Threat Defense. For information
about the classic device CLI, see Classic Device Command Line Reference, on page 2685in this guide. The
FTD and classic devices use the same commands for management interface configuration. Other commands
may differ between the platforms.

Firepower Management Center Configuration Guide, Version 6.3

1017
 Appliance Platform Settings
Configure Firepower Threat Defense or Classic Device Management Interfaces at the CLI

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.

Before you begin

• For the Firepower Threat Defense, 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 49. You can also configure
AAA users according to Configure External Authentication for SSH, on page 1095.
• For the 7000 & 8000 Series devices, you can create user accounts at the web interface as described in
Add an Internal User at the Web Interface, on page 47.

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 28 or Logging Into the Command
Line Interface on Classic Devices, on page 27.
Step 2 Log in with the Admin username and password.
Step 3 Enable an event-only interface (for supported models; see Management Interface Support, on page 1007):
configure network management-interface enable management_interface
configure network management-interface disable-management-channel management_interface
Example:
This example is for a Firepower 4100 or 9300 device; valid interface names differ by device type.

> configure network management-interface enable management1

Configuration updated successfully

> configure network management-interface disable-management-channel management1

Preserve existing configuration- currently no IP addresses on eth1 to update (bootproto
IPv4:,bootproto IPv6:
at /usr/local/sf/lib/perl/5.10.1/SF/NetworkConf/NetworkSettings.pm line 821.
Configuration updated successfully

>

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:

Firepower Management Center Configuration Guide, Version 6.3

1018
Appliance Platform Settings
Configure Firepower Threat Defense or Classic Device Management Interfaces at the CLI

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 only used to create the default route for the primary
management interface. If you set the gateway for an event-only interface, then this command ignores
the gateway and does not create a default or static route for it. You must create a static route separately
using the configure network static-routes command.
Example:

> configure network ipv4 manual 10.10.10.45 255.255.255.0 management1

Setting IPv4 network configuration.
Network settings changed.

>

• 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

Setting IPv6 network configuration.
Network settings changed.

>

• 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 only used to create the default route for the primary
management interface. If you set the gateway for an event-only interface, then this command ignores
the gateway and does not create a default or static route for it. You must create a static route separately
using the configure network static-routes command.
Example:

> configure network ipv6 manual 2001:0DB8:BA98::3210 64 management1

Setting IPv6 network configuration.
Network settings changed.

Firepower Management Center Configuration Guide, Version 6.3

1019
 Appliance Platform Settings
Configure Firepower Threat Defense or Classic Device Management Interfaces at the CLI

>

• DHCPv6 (supported on the default management interface only):

configure network ipv6 dhcp

Step 5 (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

>

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 6 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 for the default management interface (see step
4).
For information about routing, see Network Routes on Management Interfaces, on page 1010.
Example:

> configure network static-routes ipv4 add management1 192.168.6.0 255.255.255.0 10.10.10.1
Configuration updated successfully

> configure network static-routes ipv6 add management1 2001:0DB8:AA89::5110 64

2001:0DB8:BA98::3211
Configuration updated successfully

>

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

Firepower Management Center Configuration Guide, Version 6.3

1020
Appliance Platform Settings
Configure Firepower Threat Defense or Classic Device Management Interfaces at the CLI

Gateway : 10.10.10.1
Netmask : 255.255.255.0
[…]

Step 7 Set the hostname:

configure network hostname name
Example:

> configure network hostname farscape1

Syslog messages do not reflect a new hostname until after a reboot.

Step 8 Set the search domains:

configure network dns searchdomains domain_list
Example:

> 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 9 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 10 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 11 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.

Firepower Management Center Configuration Guide, Version 6.3

1021
 Appliance Platform Settings
System Shut Down and Restart

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 12 If you changed the management IP address, change the managed device IP address in the FMC according to
Editing Device Management Settings, on page 505.
If you specified a NAT ID (instead of an IP address) for the device in the FMC, then you can skip this step.

System Shut Down and Restart

Use your Firepower System's web interface to control the shut down and restart of processes on your appliance.
Shutting down the appliance prepares the system to be safely powered off and restarted without losing
configuration data.
You have several options for controlling the processes on Firepower Management Centers. You can:
• Shut down the system — Initiates a graceful shutdown of the Firepower system.
• Reboot the system — Shuts down and restarts the system in an orderly manner.
• Restart the console — Restarts the communications, database, and HTTP server processes. This is
typically used during troubleshooting.

These same options are available for 7000 and 8000 Series managed devices. You can also restart the Snort
process on these devices.

Caution Do not shut off appliances using the power button; it may cause a loss of data. Shut down appliances completely
via the web interface.

Caution Restarting the Snort process temporarily 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 312 for more information.

For Firepower virtual managed devices, the virtual infrastructure, such as VMware, typically provides
configurable power options to define the way a virtual machine is shut down, restarted, or suspended. Consult
the documentation for your virtual platform to determine how to set these options.

Firepower Management Center Configuration Guide, Version 6.3

1022
 Appliance Platform Settings
Shutting Down and Restarting the System

Note For Firepower virtual managed devices running on VMware, custom power options are part of VMware Tools,
so you must have VMware Tools installed on your virtual machines to configure graceful shut down.

Shutting Down and Restarting the System

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

7000 & 8000 Series

Procedure

Step 1 Choose System > Configuration.

Step 2 Choose Process.
Step 3 To shut down the appliance:
• FMC—Click Run Command next to Shutdown Management Center.
• Managed device—Click Run Command next to Shutdown Appliance.

Step 4 To reboot the appliance:

• FMC—Click Run Command next to Reboot Management Center.
• Managed device—Click Run Command next to Reboot Appliance.
Note When you reboot your Firepower Management Center or managed device, this logs you out of your
appliance, and the system runs a database check that can take up to an hour to complete.

Step 5 To restart the appliance:

• FMC—Click Run Command next to Restart Management Center.
• Managed device—Click Run Command next to Restart Appliance Console.
Note Restarting the Firepower Management Center may cause deleted hosts to reappear in the network
map.

Step 6 To restart the Snort process on a managed device, click Run Command next to Restart Snort.
Note This command is only available from the 7000 and 8000 Series device’s local web interface.

Caution Restarting the Snort process temporarily interrupts traffic inspection. Whether traffic drops during
this interruption or passes without inspection depends on how the device is configured. See Snort®
Restart Traffic Behavior, on page 312 for more information.

Related Topics
Snort® Restart Scenarios, on page 311

Firepower Management Center Configuration Guide, Version 6.3

1023
 Appliance Platform Settings
Remote Storage Management

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)

Note The system supports only Version 1 of the Server Message Block protocol for backup and remote storage.

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

Procedure

Step 1 Choose System > Configuration.

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

Before you begin

• Ensure that your external remote storage system is functional and accessible from your FMC.

Firepower Management Center Configuration Guide, Version 6.3

1024
 Appliance Platform Settings
Configuring SMB for Remote Storage

Procedure

Step 1 Choose System > Configuration.

Step 2 Click Remote Storage Device.
Step 3 Choose NFS from the Storage Type drop-down list.
Step 4 Add the connection information:
• 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 1027.
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

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

Before you begin

• Ensure that your external remote storage system is functional and accessible from your FMC.

Procedure

Step 1 Choose System > Configuration.

Step 2 Click Remote Storage Device.
Step 3 Choose SMB from the Storage Type drop-down list.
Step 4 Add the connection information:
• 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. Note that the system only recognizes top-level
shares and not full file paths. To use the specified Share directory as a remote backup destination, it must
be shared on the Windows system.

Firepower Management Center Configuration Guide, Version 6.3

1025
 Appliance Platform Settings
Configuring SSH for Remote Storage

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

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 1027.
Step 6 Under System Usage:
• Choose Use for Backups to store backups on the designated host.
• Choose Use for Reports to store reports on the designated host.

Step 7 To test the settings, click Test.

Step 8 Click Save.

Configuring SSH for Remote Storage

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

Before you begin

• Ensure that your external remote storage system is functional and accessible from your Firepower
Management Center.

Procedure

Step 1 Choose System > Configuration.

Step 2 Click Remote Storage Device.
Step 3 Choose SSH from the Storage Type drop-down list.
Step 4 Add the connection information:
• 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 5 Optionally, check the Use Advanced Options check box and enter any required command line options; see
Remote Storage Management Advanced Options, on page 1027.
Step 6 Under System Usage:

Firepower Management Center Configuration Guide, Version 6.3

1026
 Appliance Platform Settings
Remote Storage Management Advanced Options

• Choose Use for Backups to store backups on the designated host.

• Choose Use for Reports to store reports on the designated host.

Step 7 If you want to test the settings, you must click Test.
Step 8 Click Save.

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 77: 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

Firepower Management Center Configuration Guide, Version 6.3

1027
 Appliance Platform Settings
Configuring Change Reconciliation

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.

Configuring Change Reconciliation

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

7000 & 8000 Series

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 1041 for more information.

Procedure

Step 1 Choose System > Configuration.

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 2672

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.

Firepower Management Center Configuration Guide, Version 6.3

1028
 Appliance Platform Settings
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

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

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

Step 1 Choose System > Configuration.

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.

Firepower Management Center Configuration Guide, Version 6.3

1029
 Appliance Platform Settings
The Access List

The Access List

On Firepower Management Center and Classic managed devices, you can use access lists to limit access to
the system by IP address and port. By default, the following ports are enabled for any IP address:
• 443 (HTTPS)—Used for web interface access.
• 22 (SSH)—Used for command line access.

You can also add access to poll for SNMP information over port 161.

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.

Configuring the Access List for Your System

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

Classic

This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center 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.
Note that this access list does not control external database access.

Procedure

Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• FMC—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.

Step 2 Click Access List.

Step 3 Optionally, to delete one of the current settings, click the delete icon ( ).
Caution If you delete access for the IP address that you are currently using to connect to the appliance
interface, and there is no entry for “IP=any port=443”, you will lose access to the system when
you deploy the policy.

Firepower Management Center Configuration Guide, Version 6.3

1030
 Appliance Platform Settings
Audit Logs

Step 4 To add access for one or more IP addresses, click Add Rules.
Step 5 In the IP Address field, enter an IP address or address range, or any.
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.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Firepower System IP Address Conventions, on page 15

Audit Logs
Firepower Management Center records the activity of management center users in read-only audit logs.
Classic devices also maintain audit logs. See Audit Logs on Classic Devices, on page 1072.
You can review audit log data in several ways:
• Audit logs are presented in a standard event view in the web interface. From this event view, 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. See Auditing
the System, on page 2669.
• You can configure Firepower Management Center to send audit log messages to the syslog. See Sending
Audit Log Messages to the Syslog, on page 1031.
• You can configure Firepower Management Center to stream audit log messages to an HTTP server. See
Sending Audit Log Messages to an HTTP Server, on page 1033.

Streaming audit log data to an external syslog or HTTP server allows you to conserve space on the local
appliance.
To secure the channel for audit log streaming, enable TLS and mutual authentication using TLS certificates;
for more information, see Audit Log Certificate , on page 1034.

Caution Sending audit information to an external URL may affect system performance.

Sending Audit Log Messages to the Syslog

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

Firepower Management Center Configuration Guide, Version 6.3

1031
 Appliance Platform Settings
Sending Audit Log Messages to the Syslog

Note To send audit log messages from Classic devices to a syslog server, see Sending Audit Log Messages from
Classic Devices to the Syslog, on page 1072.

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 FROMMC, a sample audit log message could appear as follows:
Mar 01 14:45:24 localhost [FROMMC] Dev-MC7000: [email protected], Operations > Monitoring,
Page View

You can specify the severity, facility, and an optional tag associated with the messages. The tag appears with
the audit log messages in the syslog. The facility indicates the subsystem that creates the message and the
severity defines the severity of the message. Syslog messages do not include facilities and severities; these
values tell the system that receives the syslog messages how to categorize them.

Before you begin

• Ensure that the syslog server is functional and accessible from the system sending the audit log.
• You can secure the channel for audit log streaming by enabling TLS and mutual authentication using
TLS certificates; for more information, see Audit Log Certificate , on page 1034.

Procedure

Step 1 Choose System > Configuration.

Step 2 Click Audit Log.
Step 3 Choose Enabled from the Send Audit Log to Syslog drop-down menu.
Step 4 Designate the destination host for the audit information by using the IP address or the fully qualified name
of the syslog server in the Host field. The default port (6514) is used.
Caution If the computer you configure to receive an audit log is not set up to accept remote messages, the
host will not accept the audit log.

Step 5 From the Facility list, choose a facility described in Syslog Alert Facilities, on page 2288.
Step 6 From the Severity list, choose a severity described in Syslog Severity Levels, on page 2289.
Step 7 Optionally, in the Tag field, enter the tag name that you want to appear with the syslog message. For example,
if you want all audit log records sent to the syslog to be preceded with FROMMC, enter FROMMC in the field.
Step 8 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1032
 Appliance Platform Settings
Sending Audit Log Messages to an HTTP Server

Sending Audit Log Messages to an HTTP Server

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

Note To send audit log messages from Classic devices to an HTTP server, see Sending Audit Log Messages to an
HTTP Server from a Classic Device, on page 1073.

When this feature is enabled, the appliance or device 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: [email protected], Operations > Monitoring,
Page View

Before you begin

• Ensure that the external host is functional and accessible from the appliance or device sending the audit
log.
• You can secure the channel for this stream by enabling TLS and mutual authentication using SSL
certificates; for more information, see Audit Log Certificate , on page 1034.

Procedure

Step 1 Choose System > Configuration.

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

Firepower Management Center Configuration Guide, Version 6.3

1033
 Appliance Platform Settings
Audit Log Certificate

• 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

Client Certificate
To use a client certificate to secure communications between an audit log server and:
• The Firepower Management Center: See How to Securely Stream Audit Logs from the FMC, on page
1035.
• Classic devices: See How to Securely Stream Audit Logs from NGIPS Devices, on page 1075.

Note You cannot use the Management Center to work with certificates for managed devices; you must log in to
each device directly using its local web interface in order to work with certificates for those devices.

Server Certificate
You can optionally require the audit log server to provide a signed certificate.

Note If you require the server to provide a signed certificate, the client certificate must be signed by the same
certificate authority as the server certificate.

To verify the server certificate, configure the appliance to load one of more certificate revocation lists (CRLs).
The appliance compares the server certificate against those listed in the CRLs. If a server offers a certificate
that is listed in a CRL as a revoked certificate, the audit log cannot be streamed to that server. See Require
Secure Connections Between Audit Log Server and FMC, on page 1038.

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.

Firepower Management Center Configuration Guide, Version 6.3

1034
 Appliance Platform Settings
How to Securely Stream Audit Logs from the FMC

How to Securely Stream Audit Logs from the FMC

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

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 appliance and the server.
Each client certificate is unique to a specific appliance or device. If you have multiple appliances and/or
devices, follow all steps below for each appliance.
To securely stream audit logs from managed Classic devices to an external server, see How to Securely Stream
Audit Logs from NGIPS Devices, on page 1075.
Use the following procedure to securely stream the audit log from a Firepower Management Center to an
external server.

Before you begin

See ramifications of requiring client and server certificates at Audit Log Certificate , on page 1034.

Procedure

Step 1 Obtain and install a signed client certificate on your appliance:

a) Obtain a Signed Audit Log Client Certificate for the FMC, on page 1036:
Generate a Certificate Signing Request (CSR) from the appliance 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 appliance 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 appliance. See
Import an Audit Log Client Certificate into the FMC, on page 1037.
Step 2 Configure the communication channel with the server to use Transport Layer Security (TLS) and enable
mutual authentication.
See Require Secure Connections Between Audit Log Server and FMC, on page 1038.

Step 3 Configure audit log streaming if you have not yet done so: See
• Sending Audit Log Messages to the Syslog, on page 1031
• Sending Audit Log Messages to an HTTP Server, on page 1033

Firepower Management Center Configuration Guide, Version 6.3

1035
 Appliance Platform Settings
Obtain a Signed Audit Log Client Certificate for the FMC

Obtain a Signed Audit Log Client Certificate for the FMC

Smart License Classic License Supported Devices Supported Domains Access

N/A Any FMC Global only Admin

To obtain a certificate for a managed Classic device, see Obtain a Signed Audit Log Client Certificate for a
Classic Device, on page 1076.

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:
• You must generate a certificate signing request (CSR) from the device or appliance on which you will
install the certificate. (For example, you cannot generate a certificate signing request for Device B from
Appliance A.) You must generate a unique certificate signing request from each device and appliance.
• 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 1 Choose System > Configuration.

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 10 Click Generate.

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.

Firepower Management Center Configuration Guide, Version 6.3

1036
 Appliance Platform Settings
Import an Audit Log Client Certificate into the FMC

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.

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 1037.

Import an Audit Log Client Certificate into the FMC

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

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.

Note To import an audit log client certificate into a Classic managed device, see Import an Audit Log Client
Certificate into a Classic Device, on page 1077.

Before you begin

• Obtain a Signed Audit Log Client Certificate for the FMC, on page 1036.
• 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 2 Click Audit Log Certificate.
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.

Firepower Management Center Configuration Guide, Version 6.3

1037
 Appliance Platform Settings
Require Secure Connections Between Audit Log Server and FMC

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 Secure Connections Between Audit Log Server and FMC

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

The system supports validating audit log server certificates using imported CRLs in Distinguished Encoding
Rules (DER) format.

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 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.

To require certificates for Classic managed devices, see Require Secure Connections Between Audit Log
Server and 7000 and 8000 Series Devices, on page 1078.

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 1034.
• Obtain and import the client certificate following the steps in How to Securely Stream Audit Logs from
the FMC, on page 1035 and the topics referenced in that procedure.

Procedure

Step 1 On the FMC, choose System > Configuration.

Step 2 Click Audit Log Certificate.
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.

Firepower Management Center Configuration Guide, Version 6.3

1038
 Appliance Platform Settings
View the Audit Log Client Certificate on the FMC

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) To set the frequency of CRL updates, see Configuring Certificate Revocation List Downloads, on
page 196.

View the Audit Log Client Certificate on the FMC

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

You can view the audit log client certificate only for the appliance or device that you are logged in to.

Note To view the audit log certificate for a hardware 7000 or 8000 Series or ASA FirePOWER managed device,
see View the Audit Log Client Certificate on a Classic Device, on page 1079.

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.

To view the current audit log certificate on the FMC:

Procedure

Step 1 Choose System > Configuration.

Step 2 Click Audit Log Certificate.

Firepower Management Center Configuration Guide, Version 6.3

1039
 Appliance Platform Settings
Dashboard Settings

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 217

Enabling Custom Analysis Widgets for Dashboards

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

Use Custom Analysis dashboard widgets to create a visual representation of events based on a flexible,
user-configurable query.

Procedure

Step 1 Choose System > Configuration.

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
the amount of traffic on your network and speed the display of event pages when IP address resolution is
enabled.

Configuring DNS Cache Properties

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

DNS resolution caching is a system-wide setting that allows the caching of previously resolved DNS lookups.

Firepower Management Center Configuration Guide, Version 6.3

1040
 Appliance Platform Settings
Email Notifications

Procedure

Step 1 Choose System > Configuration.

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 37
Management Interfaces, on page 1006

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.

Configuring a Mail Relay Host and Notification Address

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

Procedure

Step 1 Choose System > Configuration.

Firepower Management Center Configuration Guide, Version 6.3

1041
 Appliance Platform Settings
Language Selection

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.

Specifying a Different Language

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

7000 & 8000 Series

This configuration applies to either a Firepower Management Center or a 7000 and 8000 Series managed
device.
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a 7000 and 8000 Series managed device, you apply this configuration from the Firepower Management
Center as part of a platform settings policy.

Firepower Management Center Configuration Guide, Version 6.3

1042
 Appliance Platform Settings
Login Banners

In either case, the configuration does not take effect until you save your system configuration changes or
deploy the shared platform settings policy.

Caution The language you specify here is used for the web interface for every user who logs into the appliance.

Procedure

Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• FMC—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.

Step 2 Click Language.

Step 3 Choose the language you want to use.
Step 4 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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 spaces but not tabs in banner text. You can specify multiple lines of text for the banner. If your
text includes empty lines, the system displays this as a carriage return (CR) in the banner. You can only use
ASCII characters, including new-line (press the Enter key), which counts as two characters.
When you access the security appliance through Telnet or SSH, the session closes if there is not enough system
memory available to process the banner messages, or if a TCP write error occurs when attempting to display
the banner messages.

Adding a Custom Login Banner

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

Classic

You can create a custom login banner that appears to users logging in via either SSH or the web interface.
This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.

Firepower Management Center Configuration Guide, Version 6.3

1043
 Appliance Platform Settings
SNMP Polling

• For a Classic managed device, you apply this configuration from the Firepower Management Center 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.

Procedure

Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• FMC—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.

Step 2 Choose Login Banner.

Step 3 In the Custom Login Banner field, enter the login banner text you want to use.
Step 4 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

SNMP Polling
You can enable Simple Network Management Protocol (SNMP) polling for Firepower Management Centers
and Classic managed devices. 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
• Additional MIBs for 7000 and 8000 Series managed devices that include statistics on traffic passing
through physical interfaces, logical interfaces, virtual interfaces, ARP, NDP, virtual bridges, and virtual
routers

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.

Note that enabling the SNMP feature 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.

Firepower Management Center Configuration Guide, Version 6.3

1044
 Appliance Platform Settings
Configuring SNMP Polling

Configuring SNMP Polling

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

Classic

This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center 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.

Note You must add SNMP access for any computer you plan to use to poll the system. Note that the SNMP MIB
contains information that could be used to attack your deployment. Cisco recommends that you restrict your
access list for SNMP access to the specific hosts that will be used to poll for the MIB. Cisco also recommends
you use SNMPv3 and use strong passwords for network management access.
SNMPv3 only supports read-only users and encryption with AES128.

Before you begin

• Add SNMP access for each computer you plan to use to poll the system as described in Configuring the
Access List for Your System, on page 1030.

Procedure

Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• FMC—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.

Step 2 Click SNMP.

Step 3 From the SNMP Version drop-down list, choose the SNMP version you want to use.
Step 4 You have the following choices:
• If you chose Version 1 or Version 2, enter the SNMP community name in the Community String field.
Go to step 13.
Note SNMPv2 only supports read-only communities.

• If you chose Version 3, click Add User to display the user definition page.
Note SNMPv3 only supports read-only users and encryption with AES128.

Firepower Management Center Configuration Guide, Version 6.3

1045
 Appliance Platform Settings
Time and Time Synchronization

Step 5 Enter a Username.

Step 6 Choose the protocol you want to use for authentication from the Authentication Protocol drop-down list.
Step 7 Enter the password required for authentication with the SNMP server in the Authentication Password field.
Step 8 Re-enter the authentication password in the Verify Password field.
Step 9 Choose the privacy protocol you want to use from the Privacy Protocol list, or choose None to not use a
privacy protocol.
Step 10 Enter the SNMP privacy key required by the SNMP server in the Privacy Password field.
Step 11 Re-enter the privacy password in the Verify Password field.
Step 12 Click Add.
Step 13 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Time and Time Synchronization

Synchronizing the system time on your Firepower Management Center and its managed devices is essential
to successful operation of your Firepower System.
Use a Network Time Protocol (NTP) server to synchronize system time on FMC and all devices.

Caution Unintended consequences may occur when time is not synchronized between the Firepower Management
Center and managed devices.

Synchronize Time Using a Network NTP Server

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

The best way to ensure proper synchronization between Firepower Management Center and all managed
devices is to use an NTP server on your network.

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 1047.
• Do not specify an untrusted NTP server.
• Connections to NTP servers do not use configured proxy settings.

Firepower Management Center Configuration Guide, Version 6.3

1046
 Appliance Platform Settings
Synchronize Time Without Access to a Network NTP Server

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 set the same NTP server.

Procedure

Step 1 Choose System > Configuration.

Step 2 Click Time Synchronization.
Step 3 If Serve Time via NTP is Enabled, choose Disabled.
Step 4 For the Set My Clock option, choose Via NTP from and enter the hostname or IP address of an NTP server.
If your organization has corroborative NTP servers, enter multiple NTP servers as a comma-separated list.

Step 5 Click Save.

Step 6 Set managed devices to synchronize with the same 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 and specify the same NTP server that you specified above.
b) Deploy the change to the devices.
For instructions:
• For Firepower Threat Defense devices, see Configure NTP Time Synchronization for Threat Defense,
on page 1131
• For all other devices, see Synchronizing Time on Classic Devices, on page 1087

Synchronize Time Without Access to a Network NTP Server

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

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 a virtual Firepower Management Center as an NTP server.

Procedure

Step 1 Manually set the system time on the Firepower Management Center:
a) Choose System > Configuration.

Firepower Management Center Configuration Guide, Version 6.3

1047
 Appliance Platform Settings
About Changing Time Synchronization Settings

b) Click Time Synchronization.

c) If Serve Time via NTP is Enabled, choose Disabled.
d) Click Save.
e) For Set My Clock, choose Manually in Local Configuration.
f) Click Save.
g) In the navigation panel at the left side of the screen, click Time.
h) Use the Set Time drop-down lists to set the time.
i) If the time zone displayed is not UTC, click it and set the time zone to UTC.
j) Click Save.
k) Click Done.
l) Click Apply.
Step 2 Set the Firepower Management Center to serve as an NTP server:
a) In the navigation panel at the left side of the screen, click Time Synchronization.
b) For Serve Time via NTP, choose Enabled.
c) Click Save.
Step 3 Set managed devices to synchronize with the Firepower Management Center NTP server:
a) In the Time Synchronization settings for the platform settings policy assigned to your managed devices,
set the clock to synchronize Via NTP from Management Center.
b) Deploy the change to managed devices.
For instructions:
• For Firepower Threat Defense devices, see Configure NTP Time Synchronization for Threat Defense,
on page 1131
• For all other devices, see Synchronizing Time on Classic Devices, on page 1087

About Changing Time Synchronization Settings

• 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.
• If you need to change the time manually after configuring the Firepower Management Center as an NTP
server, you need to 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
Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

1048
 Appliance Platform Settings
NTP Server Status

In addition, the current time appears in UTC at the top of the Time Synchronization page (local time is displayed
in the Manual clock setting option, if enabled).

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.

Note To view time and time source information on your NGIPS hardware device, see View Current System Time,
Source, and NTP Server Connection Status for NGIPS Devices, on page 1088.

Procedure

Step 1 Choose System > Configuration.

Step 2 Click Time.
If your appliance uses an NTP server: For information about the table entries, see NTP Server Status, on page
1049.

NTP Server Status

When the system is synchronizing time from an NTP server, you can view the NTP Status from the Firepower
Management Center's Time page (under the System > Configuration menu) and from the local web interface
of 7000 and 8000 Series devices:

Table 78: NTP Status

Column Description

NTP Server The IP address and 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.

Firepower Management Center Configuration Guide, Version 6.3

1049
 Appliance Platform Settings
Global User Configuration Settings

Column Description

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:
• 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 shell/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 1050.
• 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/shell). 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 1051.
• 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.

Set Password Reuse Limit

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global Admin

If you enable the Password Reuse Limit, you specify the number of previous passwords the system tracks
in password histories for each Firepower Management Center user, per access method (web interface or

Firepower Management Center Configuration Guide, Version 6.3

1050
 Appliance Platform Settings
Track Successful Logins

CLI/shell). Users cannot reuse passwords from their password history. If you lower the password reuse limit,
the system deletes older passwords from the history. If you then increase the limit, the system does not restore
the deleted passwords to the history.

Procedure

Step 1 Choose System > Configuration.

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global Admin

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/shell.

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 1 Choose System > Configuration.

Step 2 Click User Configuration.
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.

Firepower Management Center Configuration Guide, Version 6.3

1051
 Appliance Platform Settings
Enabling Temporary Lockouts

Enabling Temporary Lockouts

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global Admin

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 1 Choose System > Configuration.

Step 2 Click User Configuration.
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.

Session Timeouts
Unattended login sessions of the Firepower System web interface or auxiliary command line interface may
be security risks. You can configure, in minutes, the amount of idle time before a user’s login session times
out due to inactivity. You can also set a similar timeout for shell (command line) sessions.
Your deployment may have users who plan to passively, securely monitor the web interface for long periods
of time. You can exempt users from the web interface session timeout with a user configuration option. Users
with the Administrator role, whose complete access to menu options poses an extra risk if compromised,
cannot be made exempt from session timeouts.

Configuring Session Timeouts

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

Classic

This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.

Firepower Management Center Configuration Guide, Version 6.3

1052
 Appliance Platform Settings
Vulnerability Mapping

• For a Classic managed device, you apply this configuration from the Firepower Management Center 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.

Procedure

Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• FMC—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.

Step 2 Click Shell Timeout.

Step 3 You have the following choices:
• To configure session timeout for the web interface, enter a number (of minutes) in the Browser Session
Timeout (Minutes) field. The default value is 60; the maximum value is 1440 (24 hours). For information
on how to exempt users from this session timeout, see Add an Internal User at the Web Interface, on
page 47.
• To configure session timeout for the command line interface, enter a number (of minutes) in the Shell
Timeout (Minutes) field. The default value is 0; the maximum value is 1440 (24 hours).

Step 4 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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.

Firepower Management Center Configuration Guide, Version 6.3

1053
 Appliance Platform Settings
Mapping Vulnerabilities for Servers

Mapping Vulnerabilities for Servers

Smart License Classic License Supported Devices Supported Domains Access

Any Protection FMC Global only Admin

Procedure

Step 1 Choose System > Configuration.

Step 2 Choose Vulnerability Mapping.
Step 3 You have the following choices:
• 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 Cisco deployment.

Note In additon to configuring remote console access management, you can enable and disable the Firepower
Management Center CLI from the Console Configuration page. For more information see the Firepower
Management Center Command Line Reference, on page 2753.

On supported physical-hardware-based Firepower systems, you can use Lights-Out Management (LOM) on
the default (eth0) management interface 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.
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.

Firepower Management Center Configuration Guide, Version 6.3

1054
 Appliance Platform Settings
Configuring Remote Console Settings on the System

Configuring Remote Console Settings on the System

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC and 7000 & Global only Admin with LOM
8000 Series access

Before you begin

• Disable Spanning Tree Protocol (STP) on any third-party switching equipment connected to the device’s
management interface.

Procedure

Step 1 Choose System > Configuration.

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, or to use LOM/SOL on a Firepower
Management Center, Firepower 7050, or 8000 Series device.
• Choose Lights-Out Management to use LOM/SOL on a 7000 Series device (except the Firepower
7050). On these devices, you cannot use SOL and a regular serial connection at the same time.
Note When you change your remote console from Physical Serial Port to Lights-Out Management or
from Lights-Out Management to Physical Serial Port on the 70xx Family of devices (except the
Firepower 7050), you may have to reboot the appliance twice to see the expected boot prompt.

Step 4 To configure LOM via SOL, enter the necessary IPv4 settings:
• Choose the address Configuration for the system (DHCP or Manual)
• Enter the IP Address to be used for LOM.
Note The LOM IP address must be different from the management interface IP address of the system.

• Enter the Netmask for the system.

• Enter the Default Gateway for the system.

Step 5 Click Save.

What to do next
• If you configured Lights-Out Management, enable a Lights-Out Management user; see Lights-Out
Management User Access Configuration, on page 1056.

Firepower Management Center Configuration Guide, Version 6.3

1055
 Appliance Platform Settings
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.
• The password may have up to 20 alphanumeric characters, except when set on 71xx Family devices. If
LOM is enabled on a Firepower 7110, 7115, 7120, or 7125 device, the password may have up to 16
alphanumeric characters. Passwords longer than 20 or 16 characters, respectively, are not supported for
LOM users. A user’s LOM password is the same as that user’s system password. Cisco recommends that
you use a complex, non-dictionary-based password of the maximum supported length for your appliance
and change it every three months.
• Physical Firepower Management Centers and 8000 Series devices can have up to 13 LOM users. 8000
Series devices can have up to eight LOM users.

Note that if you deactivate, then reactivate, a role with LOM while a user with that role is logged in, or restore
a user or user role from a backup during that user’s login session, that user must log back into the web interface
to regain access to IPMItool commands.

Enabling Lights-Out Management User Access

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC and 7000 & Global only Admin with LOM
8000 Series access

You configure LOM and LOM users on a per-system basis using each system’s local web interface. You
cannot use the Firepower Management Center to configure LOM on a managed device. Similarly, because
users are managed independently per appliance, enabling or creating a LOM-enabled user on the Firepower
Management Center does not transfer that capability to users on managed devices.

Procedure

Step 1 Choose System > Configuration.

Step 2 Click Console Configuration.
Step 3 Click Lights Out Management.
Step 4 You have the following choices:

• To grant LOM user access to an existing user, click the edit icon ( ) next to a user name in the list.
• To grant LOM user access to a new user, click Create User.

Step 5 Under User Configuration, enable the Administrator role.

Step 6 Check the Allow Lights-Out Management Access check box.
Step 7 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1056
 Appliance Platform Settings
Serial Over LAN Connection Configuration

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, use
IPMIutil.

Note Cisco recommends using IPMItool version 1.8.12 or greater.

Linux
IPMItool is standard with many distributions and is ready to use.

Mac
You must install IPMItool on a Mac. First, confirm that your Mac has Apple's XCode Developer tools installed,
making sure that the optional components for command line development are installed (UNIX Development
and System Tools in newer versions, or Command Line Support in older versions). Then you can install
macports and the IPMItool. Use your favorite search engine for more information or try these sites:

https://developer.apple.com/technologies/tools/
http://www.macports.org/

Windows
You must compile IPMIutil on Windows. If you do not have access to a compiler, you can use IPMIutil itself
to compile. Use your favorite search engine for more information or try this site:

http://ipmiutil.sourceforge.net/

Understanding IPMI Utility Commands

Commands used for IPMI utilities are composed of segments as in the following IPMItool example:

ipmitool -I lanplus -H IP_address -U user_name command

where:
• ipmitool invokes the utility
• -I lanplus enables encryption for the session
• -H IP_address indicates the IP address of the appliance you want to access
• -U user_name is the name of an authorized user
• - command is the name of the command you want to give

Note Cisco recommends using IPMItool version 1.8.12 or greater.

The same command for Windows looks like this:

Firepower Management Center Configuration Guide, Version 6.3

1057
 Appliance Platform Settings
Configuring Serial Over LAN with IPMItool

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC and 7000 & Any Admin with LOM
8000 Series access

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC and 7000 & Any Admin with LOM
8000 Series access

Procedure

Using IPMIutil, enter the following command, and a password if prompted:

ipmiutil -J 3 -H 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. Note that not all power control commands are valid on 70xx Family devices.

Firepower Management Center Configuration Guide, Version 6.3

1058
Appliance Platform Settings
Lights-Out Management Overview

Note The baseboard management controller (BMC) for a Firepower 71xx, Firepower 82xx, or a Firepower 83xx
device is only accessible via 1Gbps link speeds when the host is powered on. When the device is powered
down, the BMC can only establish Ethernet link at 10 and 100Mbps. Therefore if LOM is being used to
remotely power the device, connect the device to the network using 10 and 100Mbps link speeds only.

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.

Table 79: 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 -N Indicates the IP address of the

remote appliance

-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 (not valid on

70xx Family devices)

Firepower Management Center Configuration Guide, Version 6.3

1059
 Appliance Platform Settings
Configuring Lights-Out Management with IPMItool

IPMItool IPMIutil Description

chassis power on power -u Powers up the appliance

chassis power off power -d Powers down the appliance (not

valid on 70xx Family devices)

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

Note Cisco recommends using IPMItool version 1.8.12 or greater.

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

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC and 7000 & Any Admin with LOM
8000 Series access

Procedure

Enter the following command for IPMItool and a password if prompted:

ipmitool -I lanplus -H IP_address -U user_name command

Configuring Lights-Out Management with IPMIutil

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC and 7000 & Any Admin with LOM
8000 Series access

Procedure

Enter the following command for IPMIutil and a password if prompted:

Firepower Management Center Configuration Guide, Version 6.3

1060
 Appliance Platform Settings
REST API Preferences

ipmiutil -J 3 -H 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

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

Note In deployments using Firepower Management Center high availability, this feature is available only in the
active Firepower Management Center.

Procedure

Step 1 Choose System > Configuration

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 checkbox.
Step 4 Click Save.

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

Firepower Management Center Configuration Guide, Version 6.3

1061
 Appliance Platform Settings
Enabling VMware Tools on the Firepower Management Center for VMware

You can also enable VMware Tools on all supported versions of ESXi. For a list of supported versions, see
the Cisco Firepower NGIPSv for VMware Quick Start Guide. 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

Smart License Classic License Supported Devices Supported Domains Access

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 for VMware Quick Start Guide.

Procedure

Step 1 Choose System > Configuration.

Step 2 Click VMware Tools.
Step 3 Click Enable VMware Tools.
Step 4 Click Save.

(Optional) Opt Out of Web Analytics Tracking

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Global only Admin

By default, in order to improve Firepower products, Cisco collects non-personally-identifiable usage data,
including but not limited to pages viewed, the time spent on a page, browser versions, product versions, user
location, and management IP addresses or hostnames of your Firepower Management Center appliances.
If you do not want Cisco to collect this data, you can opt out.

Procedure

Step 1 Choose System > Configuration.

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 136.

Firepower Management Center Configuration Guide, Version 6.3

1062
 Appliance Platform Settings
History for System Configuration

History for System Configuration

Feature Version Details

Global User 6.3 Added the Track Successful Logins setting. The system can track the number of successful
Configuration Settings logins each FMC account has performed within a selected number of days. When this feature is
enabled, on log in users see a message reporting how many times they have successfully logged
in to the system in the past configured number of days. (Applies to web interface as well as
shell/CLI access.)
Added the Password Reuse Limit setting. The system can track the password history for each
account for a configurable number of previous passwords. The system prevents all users from
re-using passwords that appear in that history. (Applies to web interface as well as shell/CLI
access.)
Added the Max Number of Login Failures and Set Time in Minutes to Temporarily Lockout
Users settings. These allow the administrator to limit the number of times in a row a user can
enter incorrect web interface login credentials before the system temporarily blocks the account
for a configurable period of time.
New screen: System > Configuration > User Configuration
Supported Platforms: FMC

HTTPS Certificates 6.3 The default HTTPS server certificate provided with the system now expires in three years. If
your appliance uses a default server certificate that was generated before you upgraded to Version
6.3, the server certificate will expire 20 years from when it was first generated. If you are using
the default HTTPS server certificate the system now provides the ability to renew it.
New/modified screens:
System > Configuration > HTTPS Certificate page > Renew HTTPS Certificate button.
Supported platforms: Physical FMCs, 7000 and 8000 Series devices

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.
Supported platforms: FMC

Firepower Management Center Configuration Guide, Version 6.3

1063
 Appliance Platform Settings
History for System Configuration

Firepower Management Center Configuration Guide, Version 6.3

1064
 CHAPTER 50
Platform Settings Policies for Managed Devices
The following topics explain platform settings policies and how to deploy them to managed devices:
• Introduction to Platform Settings, on page 1065
• Managing Platform Settings Policies, on page 1066
• Creating a Platform Settings Policy, on page 1066
• Setting Target Devices for a Platform Settings Policy, on page 1067

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
Configuring Firepower Platform Settings, on page 1069
System Configuration Settings, on page 992

Firepower Management Center Configuration Guide, Version 6.3

1065
 Appliance Platform Settings
Managing Platform Settings Policies

Managing Platform Settings Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

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 Creating a Platform Settings
Policy, on page 1066.

• Copy — To copy a platform settings policy, click the copy icon ( ).

• Edit — To modify the settings in an existing platform settings policy, click the edit icon ( ).

• Delete — To delete a policy that is not in use, click the delete icon ( ), then confirm your choice.
Caution You should not delete a policy that is the last deployed policy on any of its target devices, even
if it is out of date. Before you delete the policy completely, it is good practice to deploy a
different policy to those targets.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Creating a Platform Settings Policy

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

When you create a new platform settings policy you must, at minimum, choose the device type: Classic
managed devices or Firepower Threat Defense.

Firepower Management Center Configuration Guide, Version 6.3

1066
 Appliance Platform Settings
Setting Target Devices for a Platform Settings Policy

Note Platform settings for Firepower Threat Defense devices differ from platform settings for Classic managed
devices.

Procedure

Step 1 Choose Devices > Platform Settings.

Step 2 Click New Policy.
Step 3 Choose a device type from the drop-down list:
• Choose Firepower Settings to create a shared policy for Classic managed devices.
• Choose 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 Introduction to Firepower Platform Settings, on page 1069.
• For Threat Defense Settings, see Platform Settings for Firepower Threat Defense, on page 1091.

Step 8 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Setting Target Devices for a Platform Settings Policy

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

You can add targeted devices at the same time you create a new policy, or you can change them later.

Procedure

Step 1 Choose Devices > Platform Settings.

Firepower Management Center Configuration Guide, Version 6.3

1067
 Appliance Platform Settings
Setting Target Devices for a Platform Settings Policy

Step 2 Click the edit icon ( ) next to the platform settings policy that you want to edit.
Step 3 Click Policy Assignment.
Step 4 Do any of the following:
• To assign a device, stack, high-availability pair, or device group to the policy, select it in the Available
Devices list and click Add to Policy. You can also drag and drop.
• To remove a device assignment, click the delete icon ( ) next to a device, stack, high-availability pair,
or device group in the Selected Devices list.

Step 5 Click OK.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1068
 CHAPTER 51
Platform Settings for Classic Devices
The following topics explain Firepower platform settings and how to configure them on Classic devices:
• Introduction to Firepower Platform Settings, on page 1069
• Configuring Firepower Platform Settings, on page 1069
• The Access List, on page 1070
• Audit Logs on Classic Devices, on page 1072
• Audit Log Certificate (Classic Devices), on page 1075
• External Authentication Settings, on page 1080
• Language Selection, on page 1082
• Login Banners, on page 1083
• Session Timeouts, on page 1084
• SNMP Polling, on page 1085
• Time and Time Synchronization (Classic Devices), on page 1087

Introduction to Firepower Platform Settings

Platform settings for Firepower Classic managed devices configure a range of unrelated features whose values
you might want to share among several devices. In this case, 7000 and 8000 Series, ASA FirePOWER modules,
and NGIPSv devices. Even if you want different settings per device, you must create a shared policy and
apply it to the desired device.
Related Topics
Platform Settings Policies for Managed Devices, on page 1065
System Configuration Settings, on page 992

Configuring Firepower Platform Settings

Smart License Classic License Supported Devices Supported Domains Access

Any Any Classic Any Admin

To configure platform settings, you can edit an existing platform settings policy or create a new policy. If you
edit a platform settings policy that is currently deployed to a device, redeploy the policy after you have saved
your changes.

Firepower Management Center Configuration Guide, Version 6.3

1069
 Appliance Platform Settings
The Access List

Procedure

Step 1 Choose Devices > Platform Settings.

The Platform Settings page appears, including a list of the existing policies.

Step 2 Create a new policy or edit an existing policy.

• To create a new policy, see Creating a Platform Settings Policy, on page 1066.
• To edit an existing policy, click the edit icon ( ) next to the policy that you want to edit.
The Edit Policy page appears. You can change the policy name and policy description. For information about
configuring each aspect of the platform settings policy, see one of the following sections:
• Configuring the Access List for Your System, on page 1030
• Sending Audit Log Messages from Classic Devices to the Syslog, on page 1072
• Sending Audit Log Messages to an HTTP Server, on page 1033
• Audit Log Certificate (Classic Devices), on page 1075
• Enabling External Authentication to Classic Devices, on page 1081
• Specifying a Different Language, on page 1042
• Adding a Custom Login Banner, on page 1043
• Configuring Session Timeouts, on page 1052
• Configuring SNMP Polling, on page 1045
• Synchronizing Time on Classic Devices, on page 1087
• Enabling Security Certifications Compliance, on page 1140

Step 3 (Optional) Click Policy Assignment to choose the Available Devices where you want to deploy the policy.
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 4 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

The Access List

On Firepower Management Center and Classic managed devices, you can use access lists to limit access to
the system by IP address and port. By default, the following ports are enabled for any IP address:
• 443 (HTTPS)—Used for web interface access.
• 22 (SSH)—Used for command line access.

You can also add access to poll for SNMP information over port 161.

Firepower Management Center Configuration Guide, Version 6.3

1070
 Appliance Platform Settings
Configuring the Access List for Your System

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.

Configuring the Access List for Your System

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

Classic

This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center 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.
Note that this access list does not control external database access.

Procedure

Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• FMC—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.

Step 2 Click Access List.

Step 3 Optionally, to delete one of the current settings, click the delete icon ( ).
Caution If you delete access for the IP address that you are currently using to connect to the appliance
interface, and there is no entry for “IP=any port=443”, you will lose access to the system when
you deploy the policy.

Step 4 To add access for one or more IP addresses, click Add Rules.
Step 5 In the IP Address field, enter an IP address or address range, or any.
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.

Firepower Management Center Configuration Guide, Version 6.3

1071
 Appliance Platform Settings
Audit Logs on Classic Devices

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Audit Logs on Classic Devices

Classic devices record the activity of management center users in read-only audit logs.
You can review audit log data in several ways:
• Audit logs are presented in a standard event view in the web interface. From this event view, 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. See Auditing
the System, on page 2669.
• You can configure Classic devices to send audit log messages to the syslog. See Sending Audit Log
Messages from Classic Devices to the Syslog, on page 1072.
• You can configure Classic devices to stream audit log messages to an HTTP server. See Sending Audit
Log Messages to an HTTP Server from a Classic Device, on page 1073.

Streaming audit log data to an external syslog or HTTP server allows you to conserve space on the local
device.
To secure the channel for audit log streaming, enable TLS and mutual authentication using TLS certificates;
for more information, see Audit Log Certificate (Classic Devices), on page 1075.

Caution Sending audit information to an external URL may affect system performance.

Sending Audit Log Messages from Classic Devices to the Syslog

Smart License Classic License Supported Devices Supported Domains Access

N/A Any Classic Any Admin

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 FROMMC, a sample audit log message could appear as follows:
Mar 01 14:45:24 localhost [FROMMC] Dev-MC7000: [email protected], Operations > Monitoring,
Page View

You can specify the severity, facility, and an optional tag associated with the messages. The tag appears with
the audit log messages in the syslog. The facility indicates the subsystem that creates the message and the
severity defines the severity of the message. Syslog messages do not include facilities and severities; these
values tell the system that receives the syslog messages how to categorize them.

Firepower Management Center Configuration Guide, Version 6.3

1072
 Appliance Platform Settings
Sending Audit Log Messages to an HTTP Server from a Classic Device

Before you begin

• Ensure that the syslog server is functional and accessible from the system sending the audit log.
• You can secure the channel for audit log streaming by enabling TLS and mutual authentication using
TLS certificates; for more information, see Audit Log Certificate (Classic Devices), on page 1075.

Procedure

Step 1 Choose Devices > Platform Settings.

Step 2 Create or edit a Firepower policy.
Step 3 Click Audit Log.
Step 4 Choose Enabled from the Send Audit Log to Syslog drop-down menu.
Step 5 Designate the destination host for the audit information by using the IP address or the fully qualified name
of the syslog server in the Host field. .
Caution If the computer you configure to receive an audit log is not set up to accept remote messages, the
host will not accept the audit log.

Step 6 From the Facility list, choose a facility described in Syslog Alert Facilities, on page 2288.
Step 7 From the Severity list, choose a severity described in Syslog Severity Levels, on page 2289.
Step 8 Optionally, in the Tag field, enter the tag name that you want to appear with the syslog message. For example,
if you want all audit log records sent to the syslog to be preceded with FROMMC, enter FROMMC in the field.
Step 9 Click Save.

What to do next
• Make sure the policy is assigned to your devices. See Setting Target Devices for a Platform Settings
Policy, on page 1067.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Sending Audit Log Messages to an HTTP Server from a Classic Device

Smart License Classic License Supported Devices Supported Domains Access

N/A Any Classic Any Admin

When this feature is enabled, the appliance or device 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:

Firepower Management Center Configuration Guide, Version 6.3

1073
 Appliance Platform Settings
Sending Audit Log Messages to an HTTP Server from a Classic Device

Mar 01 14:45:24 localhost [FROMMC] Dev-MC7000: [email protected], Operations > Monitoring,

Page View

Before you begin

• Ensure that the external host is functional and accessible from the appliance or device sending the audit
log.
• You can secure the channel for this stream by enabling TLS and mutual authentication using SSL
certificates; for more information, see Audit Log Certificate , on page 1034.

Procedure

Step 1 Choose Devices > Platform Settings.

Step 2 Create or edit a Firepower policy.
Step 3 Click Audit Log.
Step 4 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 5 Choose Enabled from the Send Audit Log to HTTP Server drop-down list.
Step 6 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 7 Click Save.

What to do next
• Make sure the policy is assigned to your devices. See Setting Target Devices for a Platform Settings
Policy, on page 1067.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1074
 Appliance Platform Settings
Audit Log Certificate (Classic Devices)

Audit Log Certificate (Classic Devices)

Client Certificate
To use client certificates to secure communications between managed Classic devices and audit log servers,
see How to Securely Stream Audit Logs from NGIPS Devices, on page 1075.

Note You cannot use the Management Center to work with certificates for managed devices; you must log in to
each device directly using its local web interface in order to work with certificates for those devices.

Server Certificate
You can optionally require the audit log server to provide a signed certificate.

Note If you require the server to provide a signed certificate, the client certificate must be signed by the same
certificate authority as the server certificate.

To verify the server certificate, configure the appliance to load one of more certificate revocation lists (CRLs).
The appliance compares the server certificate against those listed in the CRLs. If a server offers a certificate
that is listed in a CRL as a revoked certificate, the audit log cannot be streamed to that server. See Require
Secure Connections Between Audit Log Server and FMC, on page 1038.

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.

How to Securely Stream Audit Logs from NGIPS Devices

Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 and 8000 Any Admin

Series

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 appliance and the server.
Each client certificate is unique to a specific appliance or device. If you have multiple appliances and/or
devices, follow all steps below for each device.
Use the following procedure to securely stream the audit log from a 7000 or 8000 series device to an external
server.

Before you begin

See ramifications of requiring client and server certificates at Audit Log Certificate , on page 1034.

Firepower Management Center Configuration Guide, Version 6.3

1075
 Appliance Platform Settings
Obtain a Signed Audit Log Client Certificate for a Classic Device

Procedure

Step 1 Obtain and install a signed client certificate on your device:

a) Obtain a Signed Audit Log Client Certificate for a Classic Device, on page 1076:
Generate a Certificate Signing Request (CSR) from the device 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 device 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 device. See Import
an Audit Log Client Certificate into a Classic Device, on page 1077.
Step 2 Configure the communication channel with the server to use Transport Layer Security (TLS) and enable
mutual authentication.
See Require Secure Connections Between Audit Log Server and 7000 and 8000 Series Devices, on page 1078.

Step 3 Configure audit log streaming if you have not yet done so: See
• Sending Audit Log Messages from Classic Devices to the Syslog, on page 1072
• Sending Audit Log Messages to an HTTP Server from a Classic Device, on page 1073

Obtain a Signed Audit Log Client Certificate for a Classic Device

Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 & 8000 Series Global only Admin

NGIPSv

Note For an ASA FirePOWER device, generate the key pair and certificate from that device.

The system generates certificate request keys in Base-64 encoded PEM format.
Use the following procedure to obtain a certificate for a 7000 or 8000 series hardware device.

Before you begin

Keep the following in mind:
• You must generate a certificate signing request (CSR) from the device or appliance on which you will
install the certificate. (For example, you cannot generate a certificate signing request for Device B from
Appliance A.) You must generate a unique certificate signing request from each device and appliance.
• To ensure security, use a globally recognized and trusted Certificate Authority (CA) to sign your
certificates.

Firepower Management Center Configuration Guide, Version 6.3

1076
 Appliance Platform Settings
Import an Audit Log Client Certificate into a Classic Device

• If you will require mutual authentication between the device and the audit log server, the same Certificate
Authority must sign both the client certificate and the server certificate.

Procedure

Step 1 Access the web-based user interface of the device. See Logging Into the Web Interface of a 7000 or 8000
Series Device, on page 25.
Step 2 Choose System > Configuration.
Step 3 Click Audit Log Certificate.
Step 4 Click Generate New CSR.
Step 5 Enter a country code in the Country Name (two-letter code) field.
Step 6 Enter a state or province postal abbreviation in the State or Province field.
Step 7 Enter a Locality or City.
Step 8 Enter an Organization name.
Step 9 Enter an Organizational Unit (Department) name.
Step 10 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 Click Generate.

Step 12 Open a new blank file with a text editor.
Step 13 Copy the entire block of text in the certificate request, including the BEGIN CERTIFICATE REQUEST and END
CERTIFICATE REQUEST lines, and paste it into a blank text file.
Step 14 Save the file as clientname.csr, where clientname is the name of the appliance where you plan to use the
certificate.
Step 15 Click Close.

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 into the device; see Import an Audit Log Client
Certificate into a Classic Device, on page 1077.

Import an Audit Log Client Certificate into a Classic Device

Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 & 8000 Series Global only Admin

NGIPSv ASA
FirePOWER

Firepower Management Center Configuration Guide, Version 6.3

1077
 Appliance Platform Settings
Require Secure Connections Between Audit Log Server and 7000 and 8000 Series Devices

Before you begin

• Obtain a Signed Audit Log Client Certificate for a Classic Device, on page 1076.
• Make sure you are importing the signed certificate for the correct device. 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 To import an audit log client certificate to an ASA FirePOWER device:

Access the command-line interface of the device and use the CLI command configure audit_cert import.

Step 2 To import an audit log client certificate into a 7000 or 8000 Series device:
a) Access the web-based user interface of the device. See Logging Into the Web Interface of a 7000 or 8000
Series Device, on page 25.
b) Choose System > Configuration.
c) Click Audit Log Certificate.
d) Click Import Audit Client Certificate.
e) 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.
f) 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.
g) Open any required intermediate certificates, copy the entire block of text for each, and paste it into the
Certificate Chain field.
h) Click Save.

Require Secure Connections Between Audit Log Server and 7000 and 8000
Series Devices
Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 and 8000 Global only Admin

Series

The system supports validating audit log server certificates using imported CRLs in Distinguished Encoding
Rules (DER) format.

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.

Firepower Management Center Configuration Guide, Version 6.3

1078
 Appliance Platform Settings
View the Audit Log Client Certificate on a Classic Device

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 (Classic Devices), on page
1075.
• Obtain and import the client certificate following the steps in How to Securely Stream Audit Logs from
NGIPS Devices, on page 1075 and the topics referenced in that procedure.

Procedure

Step 1 Access the web-based user interface of the device. See Logging Into the Web Interface of a 7000 or 8000
Series Device, on page 25.
Step 2 Choose System > Configuration.
Step 3 Click Audit Log Certificate.
Step 4 To use Transport Layer Security to securely stream the audit log to an external server, choose Enable TLS.
Step 5 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 6 To verify the certificate of the audit log server, choose Enable Mutual Authentication.
Step 7 (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 8 Verify that you have a valid server certificate generated by the same certificate authority that created the client
certificate.
Step 9 Click Save.

What to do next
(Optional) To set the frequency of CRL updates, see Configuring Certificate Revocation List Downloads, on
page 196.

View the Audit Log Client Certificate on a Classic Device

Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 and 8000 Global only Admin

Series
ASA FirePOWER

Firepower Management Center Configuration Guide, Version 6.3

1079
 Appliance Platform Settings
External Authentication Settings

You can view the audit log client certificate only for the appliance or device that you are logged in to.

Procedure

Step 1 To view the current audit log client certificate for an ASA FirePOWER device:
Access the command-line interface of that device and use the CLI command show audit_cert.

Step 2 To view the current audit log certificate for a 7000 or 8000 series hardware device:
a) Access the web-based user interface of the device. See Logging Into the Web Interface of a 7000 or 8000
Series Device, on page 25.
b) Choose System > Configuration.
c) Click Audit Log Certificate.

External Authentication Settings

If you create an authentication object referencing an external authentication server, you can enable external
authentication to let users logging into the managed device authenticate to that server, rather than using the
local database.
When you enable external authentication, the system verifies the user credentials against users on an LDAP
or RADIUS server. In addition, if a user has local, internal authentication enabled and the user credentials are
not found in the internal database, the system then checks the external server for a set of matching credentials.
If a user has the same username on multiple systems, all passwords across all servers work. Note, however,
that if authentication fails on the available external authentication servers, the system does not revert to
checking the local database.
When you enable external authentication, you can set the default user role for any user whose account is
externally authenticated. You can select multiple roles, as long as those roles can be combined. For example,
if you enable external authentication that retrieves only users in the Network Security group in your company,
you may set the default user role to include the Security Analyst role so users can access collected event data
without any additional user configuration on your part. However, if your external authentication retrieves
records for other personnel in addition to the security group, you would probably want to leave the default
role unselected.
If no access role is selected, users can log in but cannot access any functionality. After a user attempts to log
in, their account is listed on the user management page (System > Users), where you can edit the account
settings to grant additional permissions.

Tip If you configure the system to use one user role and apply the policy, then later modify the configuration to
use different default user roles, any user accounts created before the modification retain the first user role
until you modify the accounts, or delete and recreate them.

If you want to specify the set of users who can authenticate against the LDAP server for shell access or for
CAC authentication and authorization, you must create separate authentication objects for each and enable
the objects separately.

Firepower Management Center Configuration Guide, Version 6.3

1080
 Appliance Platform Settings
Enabling External Authentication to Classic Devices

If a user with internal authentication attempts to log in, the system first checks if that user is in the local user
database. If the user exists, the system then checks the username and password against the local database. If
a match is found, the user logs in successfully. If the login fails, however, and external authentication is
enabled, the system checks the user against each external authentication server in the authentication order
shown in the configuration. If the username and password match results from an external server, the system
changes the user to an external user with the default privileges for that authentication object.
If an external user attempts to log in, the system checks the username and password against the external
authentication server. If a match is found, the user logs in successfully. If the login fails, the user login attempt
is rejected. External users cannot authenticate against the user list in the local database. If the user is a new
external user, an external user account is created in the local database with the default privileges from the
external authentication object.
Related Topics
Configure External Authentication, on page 51

Enabling External Authentication to Classic Devices

Smart License Classic License Supported Devices Supported Domains Access

Any Any 7000 & 8000 Any Admin

Before you begin

• Configure external authentication objects as described in Configure External Authentication, on page
51.

Procedure

Step 1 Choose Devices > Platform Settings and create or edit a Firepower policy.
Step 2 Click External Authentication.
Step 3 From the Status drop-down list, choose Enabled.
Step 4 From the Default User Role drop-down list, choose user roles to define the default permissions you want to
grant to externally authenticated users.
Step 5 If you want to use the external server to authenticate CLI or shell access accounts, choose Enabled from the
Shell Authentication drop-down list.
Step 6 If you want to enable CAC authentication and authorization, choose an available CAC authentication object
from the CAC Authentication drop-down list. For information about configuring CAC authentication and
authorization, see Configure Common Access Card Authentication with LDAP, on page 66.
Step 7 Check the check boxes next to the each external authentication object that you want to use. If you enable more
than 1 object, then users are checked against servers in the order specified. See the next step to reorder servers.
If you enable shell authentication, you must enable an external authentication object that includes a Shell
Access Filter. CLI/shell access users can only authenticate against the server whose authentication object is
highest in the list.
If you need both CLI and CAC authentication, you must use separate authentication objects for each purpose.

Firepower Management Center Configuration Guide, Version 6.3

1081
 Appliance Platform Settings
Language Selection

Step 8 (Optional) Use the up and down arrows to change the order in which authentication servers are accessed when
an authentication request occurs.
Step 9 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Language Selection
You can use the Language page to specify a different language for the web interface.

Specifying a Different Language

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

7000 & 8000 Series

This configuration applies to either a Firepower Management Center or a 7000 and 8000 Series managed
device.
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a 7000 and 8000 Series managed device, you apply this configuration from the Firepower Management
Center 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 The language you specify here is used for the web interface for every user who logs into the appliance.

Procedure

Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• FMC—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.

Step 2 Click Language.

Step 3 Choose the language you want to use.
Step 4 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1082
 Appliance Platform Settings
Login Banners

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

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 spaces but not tabs in banner text. You can specify multiple lines of text for the banner. If your
text includes empty lines, the system displays this as a carriage return (CR) in the banner. You can only use
ASCII characters, including new-line (press the Enter key), which counts as two characters.
When you access the security appliance through Telnet or SSH, the session closes if there is not enough system
memory available to process the banner messages, or if a TCP write error occurs when attempting to display
the banner messages.

Adding a Custom Login Banner

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

Classic

You can create a custom login banner that appears to users logging in via either SSH or the web interface.
This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center 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.

Procedure

Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• FMC—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.

Step 2 Choose Login Banner.

Step 3 In the Custom Login Banner field, enter the login banner text you want to use.
Step 4 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1083
 Appliance Platform Settings
Session Timeouts

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Session Timeouts
Unattended login sessions of the Firepower System web interface or auxiliary command line interface may
be security risks. You can configure, in minutes, the amount of idle time before a user’s login session times
out due to inactivity. You can also set a similar timeout for shell (command line) sessions.
Your deployment may have users who plan to passively, securely monitor the web interface for long periods
of time. You can exempt users from the web interface session timeout with a user configuration option. Users
with the Administrator role, whose complete access to menu options poses an extra risk if compromised,
cannot be made exempt from session timeouts.

Configuring Session Timeouts

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

Classic

This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center 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.

Procedure

Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• FMC—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.

Step 2 Click Shell Timeout.

Step 3 You have the following choices:
• To configure session timeout for the web interface, enter a number (of minutes) in the Browser Session
Timeout (Minutes) field. The default value is 60; the maximum value is 1440 (24 hours). For information
on how to exempt users from this session timeout, see Add an Internal User at the Web Interface, on
page 47.
• To configure session timeout for the command line interface, enter a number (of minutes) in the Shell
Timeout (Minutes) field. The default value is 0; the maximum value is 1440 (24 hours).

Firepower Management Center Configuration Guide, Version 6.3

1084
 Appliance Platform Settings
SNMP Polling

Step 4 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

SNMP Polling
You can enable Simple Network Management Protocol (SNMP) polling for Firepower Management Centers
and Classic managed devices. 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
• Additional MIBs for 7000 and 8000 Series managed devices that include statistics on traffic passing
through physical interfaces, logical interfaces, virtual interfaces, ARP, NDP, virtual bridges, and virtual
routers

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.

Note that enabling the SNMP feature 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.

Configuring SNMP Polling

Smart License Classic License Supported Devices Supported Domains Access

Any Any FMC Any Admin

Classic

This configuration applies to either a Firepower Management Center or a Classic managed device (7000 and
8000 Series, ASA FirePOWER, and NGIPSv):
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic managed device, you apply this configuration from the Firepower Management Center 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.

Firepower Management Center Configuration Guide, Version 6.3

1085
 Appliance Platform Settings
Configuring SNMP Polling

Note You must add SNMP access for any computer you plan to use to poll the system. Note that the SNMP MIB
contains information that could be used to attack your deployment. Cisco recommends that you restrict your
access list for SNMP access to the specific hosts that will be used to poll for the MIB. Cisco also recommends
you use SNMPv3 and use strong passwords for network management access.
SNMPv3 only supports read-only users and encryption with AES128.

Before you begin

• Add SNMP access for each computer you plan to use to poll the system as described in Configuring the
Access List for Your System, on page 1030.

Procedure

Step 1 Depending on whether you are configuring a Firepower Management Center or a Classic managed device:
• FMC—Choose System > Configuration.
• Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.

Step 2 Click SNMP.

Step 3 From the SNMP Version drop-down list, choose the SNMP version you want to use.
Step 4 You have the following choices:
• If you chose Version 1 or Version 2, enter the SNMP community name in the Community String field.
Go to step 13.
Note SNMPv2 only supports read-only communities.

• If you chose Version 3, click Add User to display the user definition page.
Note SNMPv3 only supports read-only users and encryption with AES128.

Step 5 Enter a Username.

Step 6 Choose the protocol you want to use for authentication from the Authentication Protocol drop-down list.
Step 7 Enter the password required for authentication with the SNMP server in the Authentication Password field.
Step 8 Re-enter the authentication password in the Verify Password field.
Step 9 Choose the privacy protocol you want to use from the Privacy Protocol list, or choose None to not use a
privacy protocol.
Step 10 Enter the SNMP privacy key required by the SNMP server in the Privacy Password field.
Step 11 Re-enter the privacy password in the Verify Password field.
Step 12 Click Add.
Step 13 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1086
 Appliance Platform Settings
Time and Time Synchronization (Classic Devices)

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Time and Time Synchronization (Classic Devices)

Synchronizing the system time on your Firepower Management Center and its managed devices is essential
to successful operation of your Firepower System.
Use a Network Time Protocol (NTP) server to synchronize system time on FMC and all devices.

Caution Unintended consequences may occur when time is not synchronized between the Firepower Management
Center and managed devices.

Synchronizing Time on Classic Devices

Smart License Classic License Supported Devices Supported Domains Access
N/A Any 7000 & 8000 Series Any Admin
ASA FirePOWER
NGIPSv

Synchronizing the system time on your Firepower Management Center and its managed devices is essential
to successful operation of your Firepower System.

Before you begin

• If your organization has one or more NTP servers, use the same NTP server or servers for your devices
that you have configured for Time Synchronization on your FMC on the System > Configuration page.
Copy the specified value.
• If your managed devices cannot reach your NTP server or your organization does not have one, you must
configure your Firepower Management Center to serve as an NTP server. See Synchronize Time Without
Access to a Network NTP Server, on page 1047.

Procedure

Step 1 Choose Devices > Platform Settings.

Step 2 Create or edit a Firepower policy.
Step 3 Click Time Synchronization.
Step 4 Specify how time is synchronized on Classic managed devices:
• Choose Via NTP from Management Center if your Firepower Management Center is configured to
serve as an NTP server.

Firepower Management Center Configuration Guide, Version 6.3

1087
 Appliance Platform Settings
View Current System Time, Source, and NTP Server Connection Status for NGIPS Devices

• Choose Via NTP from to receive time from an NTP server on your network. In the text box, enter the
same IP address(es) or hostname(s) that you entered on your FMC on the System > Configuration >
Time Synchronization page.

Step 5 Click Save.

What to do next
• Make sure the policy is assigned to your devices. See Setting Target Devices for a Platform Settings
Policy, on page 1067.
• If your Firepower system includes FTD devices, set up time syncronization for those devices. See
Configure NTP Time Synchronization for Threat Defense, on page 1131.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Note It may take a few minutes for managed devices to synchronize with the configured NTP servers. In addition,
if you are synchronizing managed devices to a FMC that is configured as an NTP server, and the FMC itself
is configured to use an NTP server, it may take some time for the time to synchronize. This is because the
FMC must first synchronize with its configured NTP server before it can serve time to the managed device.

View Current System Time, Source, and NTP Server Connection Status for
NGIPS Devices
Smart License Classic License Supported Devices Supported Domains Access

N/A Any 7000 and 8000 Global only Admin

Series

Use this procedure to verify system time information on 7000 and 8000 Series hardware devices.
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.
In addition, the current time appears in UTC at the top of the Time Synchronization page (local time is displayed
in the Manual clock setting option, if enabled).

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 1 Log on to the local web interface of your NGIPS hardware device.

Firepower Management Center Configuration Guide, Version 6.3

1088
 Appliance Platform Settings
NTP Server Status

For information, see Logging Into the Web Interface of a 7000 or 8000 Series Device, on page 25.

Step 2 Choose System > Configuration.

Step 3 Click Time.
If your appliance uses an NTP server: For information about the table entries, see NTP Server Status, on page
1049.

NTP Server Status

When the system is synchronizing time from an NTP server, you can view the NTP Status from the Firepower
Management Center's Time page (under the System > Configuration menu) and from the local web interface
of 7000 and 8000 Series devices:

Table 80: NTP Status

Column Description

NTP Server The IP address and 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.

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.

Firepower Management Center Configuration Guide, Version 6.3

1089
 Appliance Platform Settings
NTP Server Status

Firepower Management Center Configuration Guide, Version 6.3

1090
 CHAPTER 52
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 1091
• Configure Banners, on page 1093
• Configure DNS, on page 1093
• Configure External Authentication for SSH, on page 1095
• Configure Fragment Handling, on page 1098
• Configure HTTP, on page 1099
• Configure ICMP Access Rules, on page 1101
• Configure SSL Settings , on page 1102
• Configure Secure Shell, on page 1105
• Configure SMTP, on page 1107
• Configure SNMP for Threat Defense, on page 1108
• Configure Syslog, on page 1113
• Configure Global Timeouts, on page 1129
• Configure NTP Time Synchronization for Threat Defense, on page 1131
• History for Firepower Threat Defense Platform Settings, on page 1132

Configure ARP Inspection

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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,

Firepower Management Center Configuration Guide, Version 6.3

1091
 Appliance Platform Settings
Configure ARP Inspection

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.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a 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 the Edit icon 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 670.
Step 5 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Firepower Management Center Configuration Guide, Version 6.3

1092
 Appliance Platform Settings
Configure Banners

Configure Banners
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

You can configure messages to show users when they connect to the device command line interface (CLI).

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select Banner.
Step 3 Configure the banner.
Following are some tips and requirements for banners.
• Only ASCII characters are allowed. You can use line returns (press Enter), but you cannot use tabs.
• You can dynamically add the hostname or domain name of the device by including the variables
$(hostname) or $(domain).
• Although there is no absolute length restriction on banners, Telnet or SSH sessions will close if there is
not enough system memory available to process the banner messages.
• From a security perspective, it is important that your banner discourage unauthorized access. Do not use
the words "welcome" or "please," as they appear to invite intruders in. The following banner sets the
correct tone for unauthorized access:

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.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Configure DNS
Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Access Admin

Defense Administrator
Network Admin

Firepower Management Center Configuration Guide, Version 6.3

1093
 Appliance Platform Settings
Configure DNS

The DNS resolution settings allows you to configure DNS for the data interfaces and the diagnostic interface
(in case selected). It also allows you to set variables to connect to the DNS server.

Before you begin

Ensure you have created a DNS server group. For instructions, see Creating DNS Server Group Objects, on
page 432.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a Firepower Threat Defense policy.
Step 2 Click DNS.
Step 3 Select the Enable DNS name resolution by device check box.
Step 4 Select the DNS Server Group that you have already created.
Step 5 (Optional) Enter the Expiry Entry Timer and Poll Timer values in minutes.
• Expiry entry timer specifies the time limit to remove the IP address of a resolved FQDN from the DNS
lookup table after its time-to-live (TTL) expires. Removing an entry requires the table to be recompiled,
so frequent removals can increase the processing load on the device. This setting virtually extends the
TTL.
• Poll timer specifies the time limit after which the device queries the DNS server to resolve the FQDN
that was defined in a network object group. An FQDN is resolved periodically either when the poll timer
has expired, or when the TTL of the resolved IP entry has expired, whichever occurs first.

Note The first instance of the FQDN resolution occurs when the FQDN object is deployed in an access
control policy.

Step 6 (Optional) Select the required interface objects from the available list and Add them to the Selected Interface
Objects list.
Ensure that the DNS server is reachable through the selected interface(s).
Note For Firepower Threat Defense 6.3 devices, if no interfaces are selected, and the diagnostic interface
is disabled for DNS lookup (see the next step), then the DNS resolution happens via any interface
including the diagnostic interface.
For Firepower Threat Defense 6.2.3 and below devices, to enable DNS resolution, either an interface
should be selected from the available list, or the diagnostic interface should be enabled for DNS
lookup (see the next step).

Step 7 (Optional) Select Enable DNS Lookup via diagnostic interface also check box.
If enabled, Firepower Threat Defense uses both the selected data interfaces, and the diagnostic interface for
DNS resolutions depending on the traffic.
Note Ensure that you configure an IP address to the diagnostic interface by selecting the device on the
Device Management page and editing the diagnostic interface after clicking on the Interfaces tab.

Step 8 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1094
 Appliance Platform Settings
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 372.

Configure External Authentication for SSH

Smart License Classic License Supported Devices Supported Domains Access

Any N/A FTD Any Administrator

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.
Sharing External Authentication Objects
External authentication objects can be used by the FMC, 7000 and 8000 Series, and FTD devices. You can
share the same object between all 3 types, or create separate objects.
Assigning External Authentication Objects to Devices
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 7000 and 8000 Series and FTD devices, you must enable the external authentication
object in the platform settings that you deploy to the devices. For the FTD, you can only activate one external
authentication object per policy. An LDAP object with CAC authentication enabled cannot also be used for
CLI access.
FTD Supported Fields
Only a subset of fields in the external authentication object are used for FTD SSH access. If you fill in additional
fields, they are ignored. If you also use this object for other device types, those fields will be used. This
procedure only covers the supported fields for the FTD. For other fields, see Configure External Authentication,
on page 51.
Usernames
Usernames must be Linux-valid usernames and be lower-case only, using alphanumeric characters plus period
(.) or hyphen (-). Other special characters such as at sign (@) and slash (/) are not supported. You cannot add
the admin user for external authentication. You can only add external users (as part of the External
Authentication object) in the FMC; you cannot add them at the CLI. Note that internal users can only be added
at the CLI, not in the FMC.
If you previously configured the same username for an internal user using the configure user add command,
the FTD first checks the password against the internal user, and if that fails, it checks the AAA server. Note
that you cannot later add an internal user with the same name as an external user; only pre-existing internal
users are supported.
Privilege Level
External users always have Config privileges; other user roles are not supported.

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 1105. SSH is not supported to the Diagnostic interface.

Firepower Management Center Configuration Guide, Version 6.3

1095
 Appliance Platform Settings
Configure External Authentication for SSH

• Please 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 authorization as defined in the Service-Type 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 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Click External Authentication.
Step 3 Click the Manage External Authentication Server link.
The System > Users > External Authentication screen opens in a new browser tab.

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
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
physicalDeliveryOfficeName attribute and users in the New York office have an attribute value
of NewYork for that attribute, to retrieve only users in the New York office, enter
(physicalDeliveryOfficeName=NewYork).

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

Firepower Management Center Configuration Guide, Version 6.3

1096
Appliance Platform Settings
Configure External Authentication for SSH

• (Optional) Show Advanced Options—Configure the following advanced options.

• Encryption—Click None, TLS, or SSL.
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. The
default is 30.

i) (Optional) Set the Shell Access Attribute if you want to use a shell access attribute other than the user
distinguished type. For example, on a Microsoft Active Directory Server, use the sAMAccountName shell
access attribute to retrieve shell access users by typing sAMAccountName in the Shell Access Attribute
field.
j) Set the Shell Access Filter.
Choose one of the following methods:
• To use the same filter you specified when configuring authentication settings, choose Same as
Base Filter.
• To retrieve administrative user entries based on attribute value, enter the attribute name, a
comparison operator, and the attribute value you want to use as a filter, enclosed in parentheses.
For example, if all network administrators have a manager attribute which has an attribute value
of shell, you can set a base filter of (manager=shell).

k) Click Save.
Step 5 For LDAP, if you later add or delete users on the LDAP server, you must refresh the user list and redeploy
the Platform Settings.
a) Choose System > Users > External Authentication.
b) Click the refresh icon ( ) 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 308.
Step 6 Configure a RADIUS Authentication Object.
a) In FMC, click Add External Authentication Object.
b) Set the Authentication Method to RADIUS.
c) Enter a Name and optional Description.
d) 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.

Firepower Management Center Configuration Guide, Version 6.3

1097
 Appliance Platform Settings
Configure Fragment Handling

e) (Optional) Change the Port from the default.

f) Enter a RADIUS Secret Key.
g) (Optional) Enter the Backup Sever parameters.
h) 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.

i) Under Shell Access Filter, enter a comma-separated list of usernames in the Administrator Shell
Access User List field. For example, enter jchrichton, aerynsun, rygel.
j) Click Save.
Step 7 Return to the Devices > > Platform Settings > External Authentication tab.
Step 8 Click the refresh icon ( ) 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 tab.

Step 9 Click the slider ( ) next to the External Authentication object you want to use. You can only enable one
object.
Step 10 Click Save.
Step 11 Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configure Fragment Handling

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

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 the Advanced > Security Configuration tab. Select
Devices > Device Management, edit a FTD device, and select the Interfaces tab to edit interface properties..

Firepower Management Center Configuration Guide, Version 6.3

1098
 Appliance Platform Settings
Configure HTTP

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select Fragment.
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.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Configure HTTP
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

1099
 Appliance Platform Settings
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. You can add objects as part of the procedure, but if you want to use object groups to identify
a group of IP addresses, ensure that the groups needed in the rules already exist. Select Objects > Object
Management to configure objects.

Note You cannot use the system-provided any network object group. Instead, use
any-ipv4 or any-ipv6.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select HTTP.
Step 3 Enable the HTTPS server by clicking Enable HTTP server.
Step 4 (Optional) Change the HTTPS port. The default is 443.
Step 5 Identify the interfaces and IP addresses that allow HTTPS connections.
Use this table to limit which interfaces will accept HTTPS connections, and the IP addresses of the clients
who are allowed to make those connections. You can use network addresses rather than individual IP addresses.
a) Click Add to add a new rule, or click the Edit icon 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 the + button.
• Security Zones—Add the zones that contain the interfaces to which you will allow HTTPS
connections. For interfaces not in a zone, you can type the interface name into the field below the
Selected Security Zone list and click Add. These rules will be applied to a device only if the device
includes the selected interfaces or zones.

c) Click OK.
Step 6 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Firepower Management Center Configuration Guide, Version 6.3

1100
 Appliance Platform Settings
Configure ICMP Access Rules

Configure ICMP Access Rules

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 or groups that define the desired hosts or networks, and port objects that
define the ICMP message types you want to control.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select ICMP.
Step 3 Configure ICMP rules.
a) Click Add to add a new rule, or click the Edit icon to edit an existing rule.
b) Configure the rule properties:
• Action—Whether to permit (allow) or deny (drop) matching traffic.
• ICMP Service—The port object that identifies the ICMP message type.
• Network—The network object or group that identifies the hosts or networks whose access you are
controlling.
• Security Zones—Add the zones that contain the interfaces that you are protecting. For interfaces
not in a zone, you can type the interface name into the field below the Selected Security Zone list

Firepower Management Center Configuration Guide, Version 6.3

1101
 Appliance Platform Settings
Configure SSL Settings

and click Add. These rules will be applied to a device only if the device includes the selected interfaces
or zones.

c) Click OK.
Step 4 (Optional.) Set rate limits on ICMPv4 Unreachable messages.
• Rate Limit—Sets the rate limit of unreachable messages, between 1 and 100 messages per second. The
default is 1 message per second.
• Burst Size—Sets the burst rate, between 1 and 10. This value is not currently used by the system.

Step 5 Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Configure SSL Settings

Smart License Classic License Supported Devices Supported Domains Access

Export-Compliance N/A FTD Leaf only Admin

Before you begin

You must make sure that you are running a fully licensed version of the Firepower Management Center. The
SSL Settings tab will be disabled if you are running Firepower Management Center in evaluation mode.
Additionally, the SSL Settings tab 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 Smart License Types and
Restrictions, on page 86.

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 the Edit icon 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 1103
The algorithms are listed based on the protocol version that you select. Each security protocol identifies unique
algorithm for setting up the security level.

Firepower Management Center Configuration Guide, Version 6.3

1102
 Appliance Platform Settings
About SSL Settings

Step 5 Click OK to save the changes.

What to do next
You can click Deploy to deploy the policy to the assigned devices.

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. Select the protocol version from 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).

Diffie-Hellmann Group—Choose a group from the drop-down list. Available options are Group1 - 768-bit
modulus, Group2 - 1024-bit modulus, Group5 - 1536-bit modulus, Group14 - 2048-bit modulus, 224-bit prime
order, and Group24 - 2048-bit modulus, 256-bit prime order. The default is Group1.
Elliptical Curve Diffie-Hellman Group—Choose a group from the drop-down list. Available options are
Group19 - 256-bit EC, Group20 - 384-bit EC, and Group21 - 521-bit EC. The default value is Group19.
TLSv1.2 adds support for the following ciphers:
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-GCM-SHA384
• AES256-GCM-SHA384
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-ECDSA-AES128-GCM-SHA256

Firepower Management Center Configuration Guide, Version 6.3

1103
 Appliance Platform Settings
About SSL Settings

• 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

Security Level—Lists the cipher security levels that Firepower Threat Defense device supports and uses for
SSL connections. Choose one of the following options:
All includes all ciphers, including NULL-SHA.
Low includes all ciphers, except NULL-SHA.
Medium includes all ciphers, except NULL-SHA, DES-CBC-SHA, RC4-SHA, and RC4-MD5 (this is the
default).
Fips includes all FIPS-compliant ciphers, except NULL-SHA, DES-CBC-SHA, RC4-MD5, RC4-SHA, and
DES-CBC3-SHA.
High includes only AES-256 with SHA-2 ciphers and applies to TLS version 1.2 and the default version.
Custom includes one or more ciphers that you specify in the Cipher algorithms/custom string box. This option
provides you with full control of the cipher suite using OpenSSL cipher definition strings.
Cipher Algorithms/Custom String—Lists the cipher algorithms that Firepower Threat Defense device
supports and uses for SSL connections. For more information about ciphers using OpenSSL, see
https://www.openssl.org/docs/apps/ciphers.html
The Firepower Threat Defense device specifies the order of priority for supported ciphers as:
Ciphers supported by TLSv1.2 only

ECDHE-ECDSA-AES256-GCM-SHA384

ECDHE-RSA-AES256-GCM-SHA384

Firepower Management Center Configuration Guide, Version 6.3

1104
 Appliance Platform Settings
Configure Secure Shell

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

Configure Secure Shell

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

If you want to allow SSH connections to one or more data interfaces on the FTD device, configure Secure
Shell settings. SSH is not supported to the Diagnostic logical interface. The physical management interface
is shared between the Diagnostic logical interface and the Management logical interface. SSH is enabled by
default on the Management logical interface; however, this screen does not affect Management SSH access.
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. SSH for data interfaces shares the internal and

Firepower Management Center Configuration Guide, Version 6.3

1105
 Appliance Platform Settings
Configure Secure Shell

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.

Note On all devices, after a user makes three consecutive failed attempts to log into the CLI or shell via SSH, the
system terminates the SSH connection.

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 49. 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
1095.
• You need network objects that define the hosts or networks you will allow to make SSH connections to
the device. You can add objects as part of the procedure, but if you want to use object groups to identify
a group of IP addresses, ensure that the groups needed in the rules already exist. Select Objects > Object
Management to configure objects.

Note You cannot use the system-provided any network object. Instead, use any-ipv4
or any-ipv6.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select Secure Shell.
Step 3 Identify the interfaces and IP addresses that allow SSH connections.
Use this table to limit which interfaces will accept SSH connections, and the IP addresses of the clients who
are allowed to make those connections. You can use network addresses rather than individual IP addresses.
a) Click Add to add a new rule, or click the Edit icon to edit an existing rule.
b) Configure the rule properties:

Firepower Management Center Configuration Guide, Version 6.3

1106
 Appliance Platform Settings
Configure SMTP

• 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
the + button.
• Security Zones—Add the zones that contain the interfaces to which you will allow SSH connections.
For interfaces not in a zone, you can type the interface name into the field below the Selected Security
Zone list and click Add. These rules will be applied to a device only if the device includes the selected
interfaces or zones.

c) Click OK.
Step 4 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Configure SMTP
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Click SMTP Server.
Step 3 Select the network objects that identify the Primary Server IP Address and optionally, the Secondary Server
IP Address.
Step 4 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Firepower Management Center Configuration Guide, Version 6.3

1107
 Appliance Platform Settings
Configure SNMP for Threat Defense

Configure SNMP for Threat Defense

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 only supports read-only users and encryption with AES128.

Note To create an alert to an external SNMP server, access Policies > Action > Alerts

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select SNMP.
Step 3 Enable SNMP and configure basic options.
• Enable SNMP Servers—Whether to provide SNMP information to the configured SNMP hosts. You
can deselect this option to disable SNMP monitoring while retaining the configuration information.
• Read Community String, Confirm—Enter the password used by a SNMP management station when
sending requests to the FTD device. The SNMP community string is a shared secret among the SNMP
management stations and the network nodes being managed. The security device uses the password to
determine if the incoming SNMP request is valid. The password is a case-sensitive alphanumeric string
of up to 32 characters; spaces are not permitted.
• System Administrator Name—Enter the name of the device administrator or other contact person. This
string is case-sensitive and can be up to 127 characters. Spaces are accepted, but multiple spaces are
shortened to a single space.
• Location—Enter the location of this security device (for example, Building 42,Sector 54). This string
is case-sensitive and can be up to 127 characters. Spaces are accepted, but multiple spaces are shortened
to a single space.
• Port—Enter the UDP port on which incoming requests will be accepted. The default is 161.

Step 4 (SNMPv3 only.) Add SNMPv3 Users, on page 1109.

Step 5 Add SNMP Hosts, on page 1110.
Step 6 Configure SNMP Traps, on page 1111.
Step 7 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1108
 Appliance Platform Settings
Add SNMPv3 Users

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

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. The authentication algorithm options are MD5 and SHA. The encryption
algorithm options are DES, 3DES, and AES128.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Click SNMP from the table of contents and then click the Users tab.
Step 3 Click Add.
Step 4 Select the security level for the user from the Security Level drop-down list.
• Auth—Authentication but No Privacy, which means that messages are authenticated.
• No Auth—No Authentication and No Privacy, which means that no security is applied to messages.
• Priv—Authentication and Privacy, which means that messages are authenticated and encrypted.

Step 5 Enter the name of the SNMP user in the Username field. Usernames must be 32 characters or less.
Step 6 Select the type of password, you want to use in the Encryption Password Type drop-down list.
• Clear text—The FTD device will still encrypt the password when deploying to the device.
• Encrypted—The FTD device will directly deploy the encrypted password.

Step 7 Select the type of authentication you want to use: MD5 or SHA, in the Auth Algorithm Type drop-down
list.
Step 8 In the Authentication Password field, enter the password to use for authentication. If you selected Encrypted
as the Encrypt Password Type, the password must be formatted as xx:xx:xx..., where xx are hexadecimal
values.
Note The length of the password will depend on the authentication algorithm selected. For all passwords,
the length must be 256 characters or less.

If you selected Clear Text as the Encrypt Password Type, repeat the password in the Confirm field.

Step 9 In the Encryption Type drop-down list, select the type of encryption you want to use: AES128,
AES192,AES256, 3DES, DES.
Note To use AES or 3DES encryption, you must have the appropriate license installed on the device.

Firepower Management Center Configuration Guide, Version 6.3

1109
 Appliance Platform Settings
Add SNMP Hosts

Step 10 Enter the password to use for encryption in theEncryption Password field. If you selected Encrypted as the
Encrypt Password Type, the password must be formatted as xx:xx:xx..., where xx are hexadecimal values.
For encrypted passwords, the length of the password depends on the encryption type selected. The password
sizes are as follows (where each xx is one octal):
• AES 128 requires 16 octals
• AES 192 requires 24 octals
• AES 256 requires 32 octals
• 3DES requires 32 octals
• DES can be any size

Note For all passwords, the length must be 256 characters or less.

If you selected Clear Text as the Encrypt Password Type, repeat the password in the Confirm field.

Step 11 Click OK.

Step 12 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Add SNMP Hosts

Use the Host tab 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.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Click SNMP from the table of contents and then click the Hosts tab.
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.

Firepower Management Center Configuration Guide, Version 6.3

1110
 Appliance Platform Settings
Configure SNMP Traps

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 Click Add to enter or select the interface on which this SNMP management station contacts the device.
Step 11 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.
Note Ensure that the Interface IP address does not conflict with the IP address value(s) defined for the
SNMP host in Step 4, on page 1110 .

Step 12 Click OK.

Step 13 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Configure SNMP Traps

Use the SNMP Traps tab 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:

Firepower Management Center Configuration Guide, Version 6.3

1111
 Appliance Platform Settings
Configure SNMP Traps

http://www.ietf.org/
Browse the complete list of Cisco MIBs, traps, and OIDs from the following location:
ftp://ftp.cisco.com/pub/mibs/
In addition, download Cisco OIDs by FTP from the following location:
ftp://ftp.cisco.com/pub/mibs/oid/oid.tar.gz

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Click SNMP from the table of contents and click the SNMP Traps tab 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 1125.

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:

Firepower Management Center Configuration Guide, Version 6.3

1112
 Appliance Platform Settings
Configure Syslog

• 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

Step 8 Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Configure Syslog
You can enable system logging (syslog) for FTD devices. Logging information can help you identify and
isolate network or device configuration problems. 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 81: 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.

Firepower Management Center Configuration Guide, Version 6.3

1113
 Appliance Platform Settings
Severity Levels

Logs Related To Details Configure In

(Devices This syslog configuration generates alerts for connection, Security Platform
running versions Intelligence, and intrusion events. For details, see About Sending Syslog Settings and the
6.3 and later) Messages for Connection and Intrusion Events, on page 2356 and Logging tab in
subtopics. an access control
Connection and
policy
intrusion events

(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 2286. These messages tab 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 2287.

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 82: 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.

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.

Firepower Management Center Configuration Guide, Version 6.3

1114
 Appliance Platform Settings
Syslog Message Classes

Specifically, you can direct syslog messages to an output destination according to the following criteria:
• Syslog message ID number
(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.)

Syslog Message Classes

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 83: Syslog Message Classes and Associated Message ID Numbers

Class Definition Syslog Message ID Numbers

auth User Authentication 109, 113

— Access Lists 106

Firepower Management Center Configuration Guide, Version 6.3

1115
 Appliance Platform Settings
Syslog Message Classes

Class Definition Syslog Message ID Numbers

— Application Firewall 415

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

— Blacklists, Whitelists, and Graylists 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

Firepower Management Center Configuration Guide, Version 6.3

1116
Appliance Platform Settings
Syslog Message Classes

Class Definition Syslog Message ID Numbers

— Network Access Point 713

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

Firepower Management Center Configuration Guide, Version 6.3

1117
 Appliance Platform Settings
Guidelines for Logging

Class Definition Syslog Message ID Numbers

— VXLAN 778

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.

Additional Guidelines
• The syslog server must run a server program called syslogd. Windows provides a syslog server as part
of its operating system.
• To view logs generated by the Firepower Threat Defense device, you must specify a logging output
destination. If you enable logging without specifying a logging output destination, the Firepower Threat
Defense device generates messages but does not save them to a location from which you can view them.
You must specify each different logging output destination separately.
• It is not possible to have two different lists or classes being assigned to different syslog servers or same
locations.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

1118
 Appliance Platform Settings
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

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 1120.

To configure syslog settings, perform the following steps:

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Click Syslog from the table of contents.
Step 3 Click the Logging Setup tab to enable logging, specify FTP Server settings, and specify Flash usage. For
more information, see Enable Logging and Configure Basic Settings, on page 1120
Step 4 Click the Logging Destinations tab 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 1122
You must enable a logging destination to see messages at that destination.

Step 5 Click the E-mail Setup tab 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 1123
Step 6 Click the Events List tab 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 1124
Step 7 Click the Rate Limit tab 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 1125
Step 8 Click the Syslog Settings tab 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 1126

Firepower Management Center Configuration Guide, Version 6.3

1119
 Appliance Platform Settings
FTD Platform Settings That Apply to Security Event Syslog Messages

Step 9 Click the Syslog Servers tab 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 1127

FTD Platform Settings That Apply to Security Event Syslog Messages

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 do not.
The following settings apply to syslog messages for security events as well as to messages for events related
to system health and networking:
• 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).

To configure other settings for sending syslog messages for security events, see Configuration Locations for
Security Event Syslogs, on page 2357 and subtopics.

Enable Logging and Configure Basic Settings

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

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 1120.

Firepower Management Center Configuration Guide, Version 6.3

1120
Appliance Platform Settings
Enable Logging and Configure Basic Settings

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select Syslog > Logging Setup.
Step 3 Enable logging and configure basic logging settings.
• Enable Logging—Turns on data plane system logging for the Firepower Threat Defense device.
• Enable Logging on the Failover Standby Unit—Turns on logging for the standby for the Firepower
Threat Defense device, if available.
• Send syslogs in EMBLEM format—Enables EMBLEM format logging for every logging destination.
If you enable EMBLEM, you must use the UDP protocol to publish syslog messages; EMBLEM is not
compatible with TCP.
• 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 1114.

Step 5 (Optional) Configure an FTP server if you want to save log buffer contents to the server before the buffer is
overwritten. Specify the FTP Server information.
• FTP Server Buffer Wrap— To save the buffer contents to the FTP server before it is overwritten, check
this box and enter the necessary destination information in the following fields. To remove the FTP
configuration, deselect this option.
• IP Address—Select the host network object that contains the IP address of the FTP server.
• User Name—Enter the user name to use when connecting to the FTP server.
• Path—Enter the path, relative to the FTP root, where the buffer contents should be saved.
• Password/ Confirm—Enter and confirm the password used to authenticate the user name to the FTP
server.

Step 6 (Optional) Specify Flash size if you want to save log buffer contents to flash before the buffer is overwritten.
• Flash—To save the buffer contents to the flash memory before it is overwritten, check this box.
• Maximum flash to be used by logging (KB)—Specify the maximum space to be used in the flash
memory for logging(in KB). The range is 4-8044176 bytes.
• Minimum free space to be preserved (KB)—Specifies the minimum free space to be preserved in flash
memory (in KB). The range is 0-8044176 bytes.

Step 7 Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Firepower Management Center Configuration Guide, Version 6.3

1121
 Appliance Platform Settings
Enable Logging Destinations

Enable Logging Destinations

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

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 1120.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select Syslog > Logging Destinations.
Step 3 Click Add to enable a destination and apply a logging filter, or edit an existing destination.
Step 4 In the Logging Destinations dialog box, select a destination and configure the filter to use for a destination:
a) Choose the destination you are enabling in the Logging Destination drop-down list. You can create one
filter per destination: Console, E-Mail, Internal buffer, SNMP trap, SSH Sessions, and Syslog servers.
Note Console and SSH session logging works in the diagnostic CLI only. Enter system support
diagnostic-cli.

b) In Event Class, choose the filter that will apply to all classes not listed in the table.
You can configure these filters:
• Filter on severity —Select the severity level. Messages at this level or higher are sent to the
destination
• Use Event List —Select the event list that defines the filter. You create these lists on the Event Lists
tab.
• 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 1115.
d) Click OK .
Step 5 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1122
 Appliance Platform Settings
Send Syslog Messages to an E-mail Address

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Send Syslog Messages to an E-mail Address

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

You can set up a list of recipients for syslog messages to be sent as e-mails.

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 1120.

Before you begin

• Configure an SMTP server on the SMTP Server platform settings page
• Enable Logging and Configure Basic Settings, on page 1120
• Enable Logging Destinations

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select Syslog > Email Setup.
Step 3 Specify the e-mail address that is used as the source address for syslog messages that are sent as e-mail
messages.
Step 4 Click Add to enter a new e-mail address recipient of the specified syslog messages.
Step 5 Choose the severity level of the syslog messages that are sent to the recipient from the drop-down list.
The syslog message severity filter used for the destination e-mail address causes messages of the specified
severity level and higher to be sent. For information on the levels, see Severity Levels, on page 1114.

Step 6 Click OK.

Step 7 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Firepower Management Center Configuration Guide, Version 6.3

1123
 Appliance Platform Settings
Create a Custom Event List

Create a Custom Event List

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 tab, and then
use the event list to define the logging filter for the various types of destination, in the Logging Destinations
tab.

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 1120.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select Syslog > Events List.
Step 3 Configure an event list.
a) Click Add to add a new list, or edit an existing list.
b) Enter a name for the event list in the Name field. Spaces are not allowed.
c) To identify messages based on severity or event class, select the Severity/Event Class tab and add or edit
entries.
For information on the available classes see Syslog Message Classes, on page 1115.
For information on the levels, see Severity Levels, on page 1114.
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 tab 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 1115.
For specific message numbers, see Cisco ASA Series Syslog Messages.
e) Click OK to save the event list.
Step 4 Click the Logging Destinations tab and add or edit the destination that should use the filter.
See Enable Logging Destinations, on page 1122.

Step 5 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1124
 Appliance Platform Settings
Limit the Rate of Syslog Message Generation

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Limit the Rate of Syslog Message Generation

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

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 1120.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select Syslog > Rate Limit.
Step 3 To limit message generation by severity level, click Add on the Logging Level tab and configure the following
options:
• Logging Level—The severity level you are rate limiting. For information on the levels, see Severity
Levels, on page 1114.
• 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 4 Click OK.

Step 5 To limit message generation by syslog message ID, click Add on the Syslog Level tab 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.

Firepower Management Center Configuration Guide, Version 6.3

1125
 Appliance Platform Settings
Configure Syslog Settings

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Configure Syslog Settings

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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
to Security Event Syslog Messages, on page 1120.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select Syslog > Syslog Settings.
Step 3 Select a system log facility for syslog servers to use as a basis to file messages in the Facility drop-down list.
The default is LOCAL4(20), which is what most UNIX systems expect. However, because your network
devices share available facilities, you might need to change this value for system logs.
Facility values are not typically relevant for security events. If you need to include Facility values in messages,
see Facility in Security Event Syslog Messages, on page 2362.

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
5425 syslog format.
If you select the RFC 5424 format, a “Z” is appended to the end of each timestamp to indicate that the
timestamp uses the UTC time zone.

Step 6 If you want to add a device identifier to syslog messages (which is placed at the beginning of the message),
check the Enable Syslog Device ID check box and then select the type of ID.

Firepower Management Center Configuration Guide, Version 6.3

1126
 Appliance Platform Settings
Configure a Syslog Server

• 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 the Add button.

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.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
FTD Platform Settings That Apply to Security Event Syslog Messages, on page 1120

Configure a Syslog Server

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

To configure a syslog server to handle messages generated from the data plane, perform the following steps.
(For devices running version 6.3 and later) To configure a syslog server for connection and other events, for
example, for access control rules, you can use this procedure or the procedure in Creating a Syslog Alert
Response, on page 2287. If you use this procedure, see also FTD Platform Settings That Apply to Security Event
Syslog Messages, on page 1120.

Firepower Management Center Configuration Guide, Version 6.3

1127
 Appliance Platform Settings
Configure a Syslog Server

(For devices running versions earlier than 6.3) To configure a syslog server for connection and other events,
for example, for access control rules, see Creating a Syslog Alert Response, on page 2287.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select Syslog > Syslog Server.
Step 3 Check the Allow user traffic to pass when TCP syslog server is down check box, to allow traffic if any
syslog server that is using the TCP protocol is down.
Step 4 Enter a size of the queue for storing syslog messages on the security appliance when syslog server is busy in
the Message queue size (messages) field. The minimum is 1 message. The default is 512. Specify 0 to allow
an unlimited number of messages to be queued (subject to available block memory).
Step 5 Click Add to add a new syslog server.
a) In the IP Address drop-down list, select a network host object that contains the IP address of the syslog
server.
b) Choose the protocol (either TCP or UDP) and enter the port number for communications between the
Firepower Threat Defense device and the syslog server.
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).
d) Check the Enable Secure Syslog check box to encrypt the connection between the device and server
using SSL/TLS over TCP.
Note You must select TCP as the protocol to use this option. You must also upload the certificate
required to communicate with the syslog server on the Devices > Certificates page. Finally,
upload the certificate from the Firepower Threat Defense device to the syslog server to complete
the secure relationship and allow it to decrypt the traffic. The Enable Secure Syslog option is
not supported on the device management interface.

e) Select Device Management Interface or Security Zones or Named Interfaces to communicate with
the syslog server.
• Device Management Interface: This option is applicable only to Firepower Threat Defense devices
6.3 and later versions.
Note The Device Management Interface option does not support the Enable Secure Syslog
option.

• Security Zones or Named Interfaces: Select the interfaces from the list of Available Zones and
click Add. You must also configure this name (if not already configured), and an IP address, for the
Diagnostic interface (edit the device settings from the Device Management page and select the
Interfaces tab). For more information about the management/diagnostic interface, see Diagnostic
Interface, on page 631.

Firepower Management Center Configuration Guide, Version 6.3

1128
 Appliance Platform Settings
Configure Global Timeouts

Note If the syslog server is on the network attached to the physical Management interface, enter
the name of that interface in the Interface Name field below the Selected Security Zones
list and click Add. You must also configure this name (if not already configured), and an
IP address, for the Diagnostic interface (edit the device settings from the Device
Management page and select the Interfaces tab). For more information about the
management/diagnostic interface, see Diagnostic Interface, on page 631.

f) Click OK.
Step 6 Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configure Global Timeouts

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select Timeouts.
Step 3 Configure the timeouts you want to change.
For any given setting, select Custom to define your own value, Default to return to the system default value.
In most cases, the maximum timeout is 1193 hours.
You can disable some timeouts by selecting Disable.
• Console Timeout—The idle time until a connection to the console is closed, range is 0 or 5 to 1440
minutes. The default is 0, which means the session does not time out. If you change the value, existing
console sessions use the old timeout value. The new value applies to new connections only.
• Translation Slot (xlate)—The idle time until a NAT translation slot is freed. This duration must be at
least 1 minute. The default is 3 hours.

Firepower Management Center Configuration Guide, Version 6.3

1129
 Appliance Platform Settings
Configure Global Timeouts

• Connection (Conn)—The idle time until a connection slot is freed. This duration must be at least 5
minutes. The default is 1 hour.
• Half-Closed—The idle time until a TCP half-closed connection closes. The minimum is 30 seconds.
The default is 10 minutes.
• UDP—The idle time until a UDP connection closes. This duration must be at least 1 minute. The default
is 2 minutes.
• ICMP—The idle time after which general ICMP states are closed. The default (and minimum) is 2
seconds.
• RPC/Sun RPC—The idle time until a SunRPC slot is freed. This duration must be at least 1 minute.
The default is 10 minutes.
• H.225—The idle time until an H.225 signaling connection closes. The default is 1 hour. To close a
connection immediately after all calls are cleared, a timeout of 1 second (0:0:1) is recommended.
• H.323—The idle time after which H.245 (TCP) and H.323 (UDP) media connections close. The default
(and minimum) is 5 minutes. Because the same connection flag is set on both H.245 and H.323 media
connections, the H.245 (TCP) connection shares the idle timeout with the H.323 (RTP and RTCP) media
connection.
• SIP—The idle time until a SIP signaling port connection closes. This duration must be at least 5 minutes.
The default is 30 minutes.
• SIP Media—The idle time until a SIP media port connection closes. This duration must be at least 1
minute. The default is 2 minutes. The SIP media timer is used for SIP RTP/RTCP with SIP UDP media
packets, instead of the UDP inactivity timeout.
• SIP Disconnect—The idle time after which SIP session is deleted if the 200 OK is not received for a
CANCEL or a BYE message, between 0:0:1 and 0:10:0. The default is 2 minutes (0:2:0).
• SIP Invite—The idle time after which pinholes for PROVISIONAL responses and media xlates will be
closed, between 0:1:0 and 00:30:0. The default is 3 minutes (0:3:0).
• SIP Provisional Media—The timeout value for SIP provisional media connections, between 1 and 30
minutes. The default is 2 minutes.
• Floating Connection—When multiple routes exist to a network with different metrics, the ASA uses
the one with the best metric at the time of connection creation. If a better route becomes available, then
this timeout lets connections be closed so a connection can be reestablished to use the better route. The
default is 0 (the connection never times out). To make it possible to use better routes, set the timeout to
a value between 0:0:30 and 1193:0:0.
• Xlate PAT—The idle time until a PAT translation slot is freed, between 0:0:30 and 0:5:0. The default
is 30 seconds. You may want to increase the timeout if upstream routers reject new connections using a
freed PAT port because the previous connection might still be open on the upstream device.
• TCP Proxy Reassembly—The idle timeout after which buffered packets waiting for reassembly are
dropped, between 0:0:10 and 1193:0:0. The default is 1 minute (0:1:0).
• ARP Timeout—(Transparent mode only.) The number of seconds between ARP table rebuilds, from
60 to 4294967. The default is 14,400 seconds (4 hours).

Step 4 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1130
 Appliance Platform Settings
Configure NTP Time Synchronization for Threat Defense

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Configure NTP Time Synchronization for Threat Defense

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

Use an Network Time Protocol (NTP) server to synchronize the clock settings on your devices. By default,
the device uses the Firepower Management Center server as the NTP server, but you should configure a
different NTP server if possible.

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. Copy the specified value.
• If your device cannot reach an NTP server or your organization does not have one, you must configure
your Firepower Management Center to serve as an NTP server. See Synchronize Time Without Access
to a Network NTP Server, on page 1047.

Procedure

Step 1 Select Devices > Platform Settings and create or edit a FTD policy.
Step 2 Select Time Synchronization.
Step 3 Configure one of the following clock options:
• Via NTP from Defense Center—Use the Firepower Management Center server as the NTP server if
you have configured it to serve this function. This is the default.
• Via NTP from—If your Firepower Management Center is using an NTP server on the network, select
this option and enter the fully-qualified DNS name (such as ntp.example.com), or IP address, of the same
NTP server or servers that you specified on the FMC in System > Configuration > Time
Synchronization.

Firepower Management Center Configuration Guide, Version 6.3

1131
 Appliance Platform Settings
History for Firepower Threat Defense Platform Settings

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
Policy, on page 1067.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.
• If your Firepower system includes Classic devices, set up time syncronization for those devices. See
Synchronizing Time on Classic Devices, on page 1087.

History for Firepower Threat Defense Platform Settings

Feature Version Details

Limit number of SSH login failures 6.3 When a user accesses any device via SSH
and fails three successive login attempts,
the device terminates the SSH session.

External Authentication added for SSH 6.2.3 You can now configure external
authentication for SSH access to the
Firepower Threat Defense using LDAP or
RADIUS.
New/Modified screen:
Devices > Platform Settings > External
Authentication
Supported platforms: Firepower Threat
Defense

Support for UC/APPL compliance mode 6.2.1 You can enable security certifications
compliance in CC mode or UCAPL mode.
Enabling security certifications compliance
does not guarantee strict compliance with
all requirements of the security mode
selected. For more information on
hardening procedures, refer to the
guidelines for this product provided by the
certifying entity.
New/Modified screen:
Devices > Platform Settings > UC/APPL
Compliance
Supported platforms: Any device

Firepower Management Center Configuration Guide, Version 6.3

1132
 Appliance Platform Settings
History for Firepower Threat Defense Platform Settings

Feature Version Details

SSL settings for remote access VPN 6.2.1 The Firepower Threat Defense device uses
the Secure Sockets Layer (SSL) protocol
and Transport Layer Security (TLS) to
support secure message transmission for
Remote Access VPN connection from
remote clients. You can configure SSL
versions and encryption algorithms that will
be negotiated and used for message
transmission during remote VPN access
over SSL.
New/Modified screen:
Devices > Platform Settings > SSL
Supported platforms: Firepower Threat
Defense

External Authentication for SSH and 6.1.0 Due to changes to support converged
HTML removed management access, only local users are
supported for SSH and HTML to data
interfaces. Also, you can no longer SSH to
the logical Diagnostic interface; instead you
can SSH to the logical Management
interface (which shares the same physical
port). Previously, only external
authentication was supported for SSH and
HTML access to Diagnostic and data
interfaces, while only local users were
supported to the Management interface.
New/Modified screen:
Devices > Platform Settings > External
Authentication
Supported platforms: Firepower Threat
Defense

Firepower Threat Defense support 6.0.1 This feature was introduced.

New/Modified screen:
Devices > Platform Settings
Supported platforms: Firepower Threat
Defense

Firepower Management Center Configuration Guide, Version 6.3

1133
 Appliance Platform Settings
History for Firepower Threat Defense Platform Settings

Firepower Management Center Configuration Guide, Version 6.3

1134
 CHAPTER 53
Security Certifications Compliance
The following topics describe how to configure your system to comply with security certifications standards:
• Security Certifications Compliance Modes, on page 1135
• Security Certifications Compliance Characteristics, on page 1136
• Security Certifications Compliance Recommendations, on page 1137
• Enabling Security Certifications Compliance, on page 1140

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. The Firepower System
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 the appliance out of CC or UCAPL
mode, you must reimage the appliance.

Firepower Management Center Configuration Guide, Version 6.3

1135
 Appliance Platform Settings
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 or shell 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.

By default, the system enforces auto-logout for login Yes Yes Yes Yes Yes Yes
account sessions.

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 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.

Firepower Management Center Configuration Guide, Version 6.3

1136
 Appliance Platform Settings
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 — — 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.

• If you are using Firepower Management Centers in a high-availability configuration, configure them
both to use the same security certifications compliance mode.
• When you configure Firepower Threat Defense on a Firepower 4100/9300 Chassis to operate in CC or
UCAPL mode, you should also configure the Firepower 4100/9300 Chassis to operate in CC mode. For
more information, see the Cisco FXOS Firepower Chassis Manager Configuration Guide.
• Do not configure the system to use any of the following features:
• Email reports, alerts, or data pruning notifications.

Firepower Management Center Configuration Guide, Version 6.3

1137
 Appliance Platform Settings
Appliance Hardening

• 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 SSO in deployments using CC mode.

• Do not enable CACs in deployments using CC mode.
• Disable access to the Firepower Management Center and managed devices via the Firepower REST API
in deployments using CC or UCAPL mode.
• Enable CACs in deployments using UCAPL mode.
• Do not configure Firepower Threat Defense devices into a high availability pair unless they are both
using the same security certifications compliance mode.

Note The Firepower System does not support CC or UCAPL mode for:
• Classic devices in stacks or high availability pairs
• Firepower Threat Defense devices in clusters
• Firepower Threat Defense container instances on the Firepower 4100/9300

Appliance Hardening
See the following topics for information about features you can use to further harden Firepower:
• Licensing the Firepower System, on page 79
• About User Accounts, on page 43
• Logging into the Firepower System, on page 19
• Audit Logs, on page 1031
• Audit Log Certificate , on page 1034
• Time and Time Synchronization, on page 1046
• Configure NTP Time Synchronization for Threat Defense, on page 1131
• Creating an Email Alert Response, on page 2290
• Configuring Email Alerting for Intrusion Events, on page 2297
• Configure SMTP, on page 1107
• Configuring SNMP for the Firepower 2100 Series, on page 517

Firepower Management Center Configuration Guide, Version 6.3

1138
 Appliance Platform Settings
Protecting Your Network

• Configure SNMP for Threat Defense, on page 1108

• Creating an SNMP Alert Response, on page 2286
• Configure DDNS, on page 691
• DNS Cache, on page 1040
• Auditing the System, on page 2669
• The Access List, on page 1030
• Security Certifications Compliance, on page 1135
• Configuring SSH for Remote Storage, on page 1026
• Audit Log Certificate , on page 1034
• HTTPS Certificates, on page 997
• Customize User Roles for the Web Interface, on page 68
• Add an Internal User Account, on page 47
• Session Timeouts, on page 1052
• Configure Syslog, on page 1113
• Backup Task Automation, on page 194
• Site-to-Site VPNs for Firepower Threat Defense, on page 857
• Remote Access VPNs for Firepower Threat Defense, on page 869
• FlexConfig Policies for Firepower Threat Defense, on page 953

Protecting Your Network

See the following topics to learn about Firepower System features you can configure to protect your network:
• Getting Started with Access Control Policies, on page 1349
• Security Intelligence Blacklisting, on page 1405
• Getting Started with Intrusion Policies, on page 1667
• Tuning Intrusion Policies Using Rules, on page 1675
• The Intrusion Rules Editor, on page 1729
• Update Intrusion Rules, on page 150
• Globally Limiting Intrusion Event Logging, on page 1723
• Transport & Network Layer Preprocessors, on page 1947
• Detecting Specific Threats, on page 1981
• Application Layer Preprocessors, on page 1871
• IPS Device Deployments and Configuration, on page 535

Firepower Management Center Configuration Guide, Version 6.3

1139
 Appliance Platform Settings
Enabling Security Certifications Compliance

• Auditing the System, on page 2669

• Working with Intrusion Events, on page 2489
• Searching for Events, on page 2413
• Workflows, on page 2371
• Device Management Basics, on page 497
• Login Banners, on page 1043
• System Software Updates, on page 145

Enabling Security Certifications Compliance

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin

This configuration applies to a Firepower Management Center, a Classic managed device (7000 and 8000
Series, ASA FirePOWER, and NGIPSv), or Firepower Threat Defense:
• For the Firepower Management Center, this configuration is part of the system configuration.
• For a Classic or Firepower Threat Defense managed device, you apply this configuration from the
Firepower Management Center as part of a platform settings policy.

In any 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 the appliance.

Before you begin

• Cisco recommends registering all devices that you plan to be part of your deployment to the Firepower
Management Center before enabling security certifications compliance on any appliances.
• For Firepower Threat Defense devices, ensure that you are not using an evaluation license. The device
must be registered through a Smart Software Manager account that is enabled for export-controlled
features.
• Firepower Threat Defense devices must be deployed in routed mode to support security certifications
compliance.

Procedure

Step 1 Depending on the type of appliance you are configuring:

Firepower Management Center Configuration Guide, Version 6.3

1140
Appliance Platform Settings
Enabling Security Certifications Compliance

• FMC—Choose System > Configuration.

• Classic Managed device—Choose Devices > Platform Settings and create or edit a Firepower policy.
• Firepower Threat Defense—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 Firepower Management Center
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 the Control and Protection licenses to all classic appliances in your
deployment.
• Establish additional configuration changes as described in the guidelines for this product provided by
the certifying entity.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1141
 Appliance Platform Settings
Enabling Security Certifications Compliance

Firepower Management Center Configuration Guide, Version 6.3

1142
PA R T XV
Network Address Translation (NAT)
• NAT Policy Management, on page 1145
• NAT for 7000 and 8000 Series Devices, on page 1151
• Network Address Translation (NAT) for Firepower Threat Defense, on page 1169
 CHAPTER 54
NAT Policy Management
The following topics describe how to manage NAT policies for your Firepower System:
• Managing NAT Policies, on page 1145
• Creating NAT Policies, on page 1146
• Configuring NAT Policies, on page 1147
• Configuring NAT Policy Targets, on page 1148
• Copying NAT Policies, on page 1149

Managing NAT Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Any Access Admin

Administrator
FTD
Network Admin

In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
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 the copy icon ( ) next to the policy you want to copy; see Copying NAT Policies, on
page 1149.
• Create — Click New Policy; see Creating NAT Policies, on page 1146.

Firepower Management Center Configuration Guide, Version 6.3

1145
 Network Address Translation (NAT)
Creating NAT Policies

• Delete — Click the delete icon ( ) 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—Click Deploy; see Deploy Configuration Changes, on page 308.

• Edit — Click the edit icon ( ); see Configuring NAT Policies, on page 1147.

• Report—Click the report icon ( ); see Generating Current Policy Reports, on page 317.

Creating NAT Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Any Access Admin

Administrator
FTD
Network Admin

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.
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 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 From the New Policy drop-down list, choose one of the following:
• Firepower NAT for 7000 & 8000 Series devices.
• Threat Defense NAT for FTD devices.

Step 3 Enter a unique Name.

Firepower Management Center Configuration Guide, Version 6.3

1146
 Network Address Translation (NAT)
Configuring NAT Policies

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 Optionally, enter a Description.

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 the delete icon ( ) next to the device.

Step 6 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring NAT Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Any Access Admin

Administrator
FTD
Network Admin

In a multidomain deployment, the system displays policies created in the current domain, which you can edit.
It also displays policies created in ancestor domains, which you cannot edit. To view and edit policies created
in a lower domain, switch to that domain.
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.
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.

Note Rule attributes differ by NAT policy type. When adding or editing rules, click ? in the dialog box for more
information, or see the relevant chapter: Network Address Translation (NAT) for Firepower Threat Defense,
on page 1169 or NAT for 7000 and 8000 Series Devices, on page 1151.

Procedure

Step 1 Choose Devices > NAT .

Step 2 Click the edit icon ( ) next to the NAT policy you want to modify.

Firepower Management Center Configuration Guide, Version 6.3

1147
 Network Address Translation (NAT)
Configuring NAT Policy Targets

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

Step 3 Configure your NAT policies:

• 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 1148.
• To save your policy changes, click Save.
• To add a rule to a policy, click Add Rule.
• To edit an existing rule, click the edit icon ( ) next to the rule.
• To delete a rule, click the delete icon ( ) 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.
• (Firepower NAT only.) To display the configuration page for a specific rule attribute, click the name,
value, or icon in the column for the condition on the row for the rule. For example, click the name or
value in the Source Networks column to display the Source Network page for the selected rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring NAT Policy Targets

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Any Access Admin

Administrator
FTD
Network Admin

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, 7000 or 8000 Series stacks, and high-availability pairs, and add
them to a list of selected devices.
You cannot target stacked devices running different versions of the Firepower System (for example, if an
upgrade on one of the devices fails).
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 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.

Firepower Management Center Configuration Guide, Version 6.3

1148
 Network Address Translation (NAT)
Copying NAT Policies

Procedure

Step 1 Choose Devices > NAT .

Step 2 Click the edit icon ( ) next to the NAT policy you want to modify.

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

Step 3 Click Policy Assignments.

Step 4 Do any of the following:
• To assign a device, stack, high-availability pair, or device group to the policy, select it in the Available
Devices list and click Add to Policy. You can also drag and drop.
• To remove a device assignment, click the delete icon ( ) next to a device, stack, high-availability pair,
or device group in the Selected Devices list.

Step 5 Click OK.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Copying NAT Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Any Access Admin

Administrator
FTD
Network Admin

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 1 Choose Devices > NAT .

Step 2 Click the copy icon ( ) 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.

Firepower Management Center Configuration Guide, Version 6.3

1149
 Network Address Translation (NAT)
Copying NAT Policies

Firepower Management Center Configuration Guide, Version 6.3

1150
 CHAPTER 55
NAT for 7000 and 8000 Series Devices
The following topics describe how to configure NAT for 7000 and 8000 Series devices:
• NAT Policy Configuration, on page 1151
• Rule Organization in a NAT Policy, on page 1152
• Organizing NAT Rules, on page 1153
• NAT Policy Rules Options, on page 1154

NAT Policy Configuration

You can configure NAT policies in different ways to manage specific network needs. You can:
• Expose an internal server to an external network.
In this configuration, you define a static translation from an external IP address to an internal IP address
so the system can access an internal server from outside the network. Traffic sent to the server targets
the external IP address or IP address and port, and is translated into the internal IP address or IP address
and port. Return traffic from the server is translated back to the external address.
• Allow an internal host/server to connect to an external application.
In this configuration, you define a static translation from an internal address to an external address. This
definition allows the internal host or server to initiate a connection to an external application that is
expecting the internal host or server to have a specific IP address and port. Therefore, the system cannot
dynamically allocate the address of the internal host or server.
• Hide private network addresses from an external network.
You can obscure your internal network addresses using either of the following configurations:
• If you have a sufficient number of external IP addresses to satisfy your internal network needs, you
can use a block of IP addresses. In this configuration, you create a dynamic translation that
automatically converts the source IP address of any outgoing traffic to an unused IP address from
your externally facing IP addresses.
• If you have an insufficient number of external IP addresses to satisfy your internal network needs,
you can use a limited block of IP addresses and port translation. In this configuration, you create a
dynamic translation that automatically converts the source IP address and port of outgoing traffic
to an unused IP address and port from your externally facing IP addresses.

Firepower Management Center Configuration Guide, Version 6.3

1151
 Network Address Translation (NAT)
NAT Policies Configuration Guidelines

Caution In 7000 or 8000 Series device high-availability pairs, only select an individual peer interface for a static NAT
rule on a paired device if all networks affected by the NAT translations are private. Do not use configurations
for static NAT rules affecting traffic between public and private networks.

NAT Policies Configuration Guidelines

To configure a NAT policy, you must give the policy a unique name and identify the devices, or targets,
where you want to deploy the policy. You can also add, edit, delete, enable, and disable NAT rules. After you
create or modify a NAT policy, you can deploy the policy to all or some targeted devices.
You can deploy NAT policies to a 7000 or 8000 Series device high-availability pair, including paired stacks,
as you would a standalone device. However, you can define static NAT rules for interfaces on individual
paired devices or the entire high-availability pair and use the interfaces in source zones. For dynamic rules,
you can use only the interfaces on the whole high-availability pair in source or destination zones.

Caution In 7000 or 8000 Series device high-availability pairs, only select an individual peer interface for a static NAT
rule on a paired device if all networks affected by the NAT translations are private. Do not use this configuration
for static NAT rules affecting traffic between public and private networks.

If you configure dynamic NAT on a device high-availability pair without HA link interfaces established, both
paired devices independently allocate dynamic NAT entries, and the system cannot synchronize the entries
between devices.
You can deploy NAT policies to a device stack as you would a standalone device. If you establish a device
stack from devices that were included in a NAT policy and had rules associated with interfaces from the
secondary device that was a member of the stack, the interfaces from the secondary device remain in the NAT
policy. You can save and deploy policies with the interfaces, but the rules do not provide any translation.

Note Active FTP is not supported on a 7000 or 8000 series device with NAT configured, use passive FTP instead.

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 target NAT policies to
devices in descendant domains, which descendant domains can use or replace with customized local policies

Rule Organization in a NAT Policy

The Edit page for the NAT policy lists static NAT rules and dynamic NAT rules separately. The system sorts
static rules alphabetically by name, and you cannot change the display order. You cannot create static rules
with identical matching values. The system inspects static translations for a match before it inspects any
dynamic translations.
Dynamic rules are processed in numerical order. The numeric position of each dynamic rule appears on the
left side of the page next to the rule. You can move or insert dynamic rules and otherwise change the rule

Firepower Management Center Configuration Guide, Version 6.3

1152
 Network Address Translation (NAT)
Organizing NAT Rules

order. For example, if you move dynamic rule 10 under dynamic rule 3, rule 10 becomes rule 4 and all
subsequent numbers increment accordingly.
A dynamic rule’s position is important because the system compares packets to dynamic rules in the rules'
numeric order on the policy Edit page. When a packet meets all the conditions of a dynamic rule, the system
applies the conditions of that rule to the packet and ignores all subsequent rules for that packet.
You can specify a dynamic rule’s numeric position when you add or edit a dynamic rule. You can also highlight
a dynamic rule before adding a new dynamic rule to insert the new rule below the rule you highlighted.
You can select one or more dynamic rules by clicking a blank space in the row for the rule. You can drag and
drop selected dynamic rules into a new location, thereby changing the position of the rules you moved and
all subsequent rules.
You can cut or copy selected rules and paste them above or below an existing rule. You can only paste static
rules in the Static Translations list and only dynamic rules in the Dynamic Translations list. You can also
delete selected rules and insert new rules into any location in the list of existing rules.
You can display explanatory warnings to identify rules that will never match because they are preempted by
preceding rules.
If you have access control policies in your deployment, the system does not translate traffic until it has passed
through access control.

Organizing NAT Rules

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Any Admin/Network

Admin

Procedure

Step 1 Choose Devices > NAT .

Step 2 Click the edit icon ( ) next to the NAT policy you want to modify.

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

Step 3 Organize your NAT rules:

• To choose a rule, click a blank area in the row for a rule.
• To clear rule selections, click the reload icon ( ) on the lower right side of the page. To clear individual
rules, click a blank area in a rule's row while holding the Ctrl key.
• To cut or copy selected rules, right-click a blank area in the row for a selected rule, then select Cut or
Copy.
• To paste rules you have cut or copied into the rule list, right-click a blank area in the row for a rule where
you want to paste selected rules, then select Paste above or Paste below.
• To move selected rules, drag and drop selected rules beneath a new location, indicated by a horizontal
blue line that appears above your pointer as you drag.

Firepower Management Center Configuration Guide, Version 6.3

1153
 Network Address Translation (NAT)
NAT Rule Warnings and Errors

• To delete a rule, click the delete icon ( ) next to the rule, then click OK.
• To show warnings, click Show Warnings.

NAT Rule Warnings and Errors

The conditions of a NAT rule may preempt a subsequent rule from matching traffic. Any type of rule condition
can preempt a subsequent rule.
A rule also preempts an identical subsequent rule where all configured conditions are the same. A subsequent
rule would not be preempted if any condition were different.

If you create a rule that causes the NAT policy to fail upon deploy, an error icon ( ) appears next to the rule.
An error occurs if there is a conflict in the static rules, or if you edit a network object used in the policy that
now makes the policy invalid. For example, an error occurs if you change a network object to use only IPv6
addresses and the rule that uses that object no longer has any valid networks where at least one network is
required. Error icons appear automatically; you do not have to click Show Warnings.

Showing and Hiding NAT Rule Warnings

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Any Admin/Network

Admin

Procedure

Step 1 Choose Devices > NAT .

Step 2 Click the edit icon ( ) next to the NAT policy you want to modify.

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

Step 3 To show warnings, click Show Warnings.

The page updates with an warning icon ( ) next to each preempted rule.

Step 4 To display the warning for a rule, hover your pointer over the warning icon ( ) next to a rule.
A message indicates which rule preempts the rule.
Step 5 To clear warnings, click Hide Warnings.
The page refreshes and the warnings disappear.

NAT Policy Rules Options

A NAT rule is simply a set of configurations and conditions that:

Firepower Management Center Configuration Guide, Version 6.3

1154
 Network Address Translation (NAT)
Creating and Editing NAT Rules

• qualifies network traffic

• specifies how the traffic that matches those qualifications is translated

You create and edit NAT rules from within an existing NAT policy. Each rule belongs to only one policy.
The web interface for adding or editing a rule is similar. You specify the rule name, state, type, and position
(if dynamic) at the top of the page. You build conditions using the tabs on the left side of the page; each
condition type has its own tab.
The following list summarizes the configurable components of a NAT rule.

Name
Give each rule a unique name. For static NAT rules, use a maximum of 22 characters. For dynamic NAT
rules, use a maximum of 30 characters. You can use printable characters, including spaces and special characters,
with the exception of the colon (:).

Rule State
By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic for
translation. When viewing the list of rules in a NAT policy, disabled rules are grayed out, although you can
still modify them.

Type
A rule’s type determines how the system handles traffic that matches the rule’s conditions. When you create
and edit NAT rules, the configurable components vary according to rule type.

Position (Dynamic Rules Only)

Dynamic rules in a NAT policy are numbered, starting at 1. The system matches traffic to NAT rules in
top-down order by ascending rule number.
When you add a rule to a policy, you specify its position by placing it above or below a specific rule, using
rule numbers as a reference point. When editing an existing rule, you can Move the rule in a similar fashion.

Conditions
Rule conditions identify the specific traffic you want to translate. Conditions can match traffic by any
combination of multiple attributes, including security zone, network, and transport protocol port.
Related Topics
Creating and Editing NAT Rules, on page 1155

Creating and Editing NAT Rules

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Any Admin/Network

Admin

Firepower Management Center Configuration Guide, Version 6.3

1155
 Network Address Translation (NAT)
NAT Rule Types

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

Procedure

Step 1 Choose Devices > NAT .

Step 2 Click the edit icon ( ) next to the NAT policy where you want to add a rule.

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

Step 3 Add a new rule or edit an existing rule:

• To add a new rule, click Add Rule.
• To edit an existing rule, click the edit icon ( ) next to the rule you want to edit.

Step 4 Enter a unique rule Name.

Step 5 Configure the following rule components:
• Specify whether the rule is Enabled.
• Specify a rule Type.
• Specify the rule position (dynamic rules only).
• Configure the rule’s conditions.
Note Static rules must include an original destination network. Dynamic rules must include a translated
source network.

Step 6 Click Add.

Step 7 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

NAT Rule Types

Every NAT rule has an associated type that:
• qualifies network traffic
• specifies how the traffic that matches those qualifications is translated

The following list summarizes the NAT rule types.

Firepower Management Center Configuration Guide, Version 6.3

1156
Network Address Translation (NAT)
NAT Rule Types

Static
Static rules provide one-to-one translations on destination networks and optionally port and protocol. When
configuring static translations, you can configure source zones, destination networks, and destination ports.
You cannot configure destination zones or source networks.
You must specify an original destination network. For destination networks, you can only select network
objects and groups containing a single IP address or enter literal IP addresses that represent a single IP address.
You can only specify a single original destination network and a single translated destination network.

Note The system builds a separate network map for each leaf domain. In a multi-domain 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.

You can specify a single original destination port and a single translated destination port. You must specify
an original destination network before you can specify an original destination port. In addition, you cannot
specify a translated destination port unless you also specify an original destination port, and the translated
value must match the protocol of the original value.

Caution For static NAT rules on a 7000 or 8000 Series device in a high-availability pair, only select an individual peer
interface if all networks affected by the NAT translations are private. Do not use this configuration for static
NAT rules affecting traffic between public and private networks.

Dynamic IP Only
Dynamic IP Only rules translate many-to-many source networks, but maintain port and protocol. When
configuring dynamic IP only translations, you can configure zones, source networks, original destination
networks, and original destination ports. You cannot configure translated destination networks or translated
destination ports.
You must specify at least one translated source network. If the number of translated source network values
is less than the number of original source networks, the system displays a warning on the rule that it is possible
to run out of translated addresses before all original addresses are matched.
If there are multiple rules with conditions that match the same packet, the low priority rules become dead,
meaning they can never be triggered. The system also displays warnings for dead rules. You can view tooltips
to determine which rule supersedes the dead rule.

Note You can save and deploy policies with dead rules, but the rules cannot provide any translation.

In some instances, you may want to create rules with limited scope preceding rules with a broader scope. For
example:

Rule 1: Match on address A and port A/Translate to address B

Rule 2: Match on address A/Translate to Address C

In this example, rule 1 matches some packets that also match rule 2. Therefore, rule 2 is not completely dead.
If you specify only original destination ports, you cannot specify translated destination ports.

Firepower Management Center Configuration Guide, Version 6.3

1157
 Network Address Translation (NAT)
NAT Rule Condition Types

Dynamic IP + Port
Dynamic IP and port rules translate many-to-one or many-to-many source networks and port and protocol.
When configuring dynamic IP and port translations, you can configure zones, source networks, original
destination networks, and original destination ports. You cannot configure translated destination networks or
translated destination ports.
You must specify at least one translated source network. If there are multiple rules with conditions that match
the same packet, the low priority rules become dead, meaning they can never be triggered. The system also
displays warnings for dead rules. You can view tool tips to determine which rule supersedes the dead rule.

Note You can save and deploy policies with dead rules, but the rules cannot provide any translation.

If you specify only original destination ports, you cannot specify translated destination ports.

Note If you create a dynamic IP and port rule, and the system passes traffic that does not use a port, no translation
occurs for the traffic. For example, a ping (ICMP) from an IP address that matches the source network does
not map, because ICMP does not use a port.

NAT Rule Condition Types

The following table summarizes the NAT rule condition types that can be configured based on the specified
NAT rule type:

Table 84: Available NAT Rule Condition Types per NAT Rule Type

Condition Static Dynamic (IP Only or IP + Port)

Source Zones Optional Optional

Destination Zones Not allowed Optional

Original Source Networks Not allowed Optional

Translated Source Networks Not allowed Required

Original Destination Networks Required Optional

Translated Destination Networks Optional; single address only Not allowed

Original Destination Ports Optional; single port only, and only allowed Optional
if you define the original destination
network

Translated Destination Ports Optional; single port only, and only allowed Not allowed
if you define the original destination port

Firepower Management Center Configuration Guide, Version 6.3

1158
 Network Address Translation (NAT)
NAT Rule Conditions and Condition Mechanics

NAT Rule Conditions and Condition Mechanics

You can add conditions to NAT rules to identify the type of traffic that matches the rule. For each condition
type, you select conditions you want to add to a rule from a list of available conditions. When applicable,
condition filters allow you to constrain available conditions. Lists of available and selected conditions may
be as short as a single condition or many pages long. You can search available conditions and display only
those matching a typed name or value in a list that updates as you type.
Depending on the type of condition, lists of available conditions may be comprised of a combination of
conditions provided directly by Cisco or configured using other Firepower System features, including objects
created using the object manager (Objects > Object Management), objects created directly from individual
conditions pages, and literal conditions.

NAT Rule Conditions

You can set a NAT rule to match traffic meeting any of the conditions described in the following table:

Table 85: NAT Rule Condition Types

Condition Description

Zones A configuration of one or more routed interfaces

where you can deploy NAT policies. Zones provide
a mechanism for classifying traffic on source and
destination interfaces, and you can add source and
destination zone conditions to rules.

Networks Any combination of individual IP addresses, CIDR

blocks, and prefix lengths, either specified explicitly
or using network objects and groups.You can add
source and destination network conditions to NAT
rules.

Destination Ports Transport protocol ports, including individual and

group port objects you create based on transport
protocols.

Adding Conditions to NAT Rules

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Any Admin/Network

Admin

Adding conditions to NAT rules is essentially the same for each type of condition. You choose from a list of
available conditions on the left, and add the conditions you chose to one or two lists of selected conditions
on the right.
For all condition types, you choose one or more individual available conditions by clicking on them to highlight
them. You can either click a button between the two types of lists to add available conditions that you choose
to your lists of selected conditions, or drag and drop available conditions that you choose into the list of
selected conditions.

Firepower Management Center Configuration Guide, Version 6.3

1159
 Network Address Translation (NAT)
Adding Conditions to NAT Rules

You can add up to 50 conditions of each type to a list of selected conditions. For example, you can add up to
50 source zone conditions, up to 50 destination zone conditions, up to 50 source network conditions, and so
on, until you reach the upper limit for the appliance.

Procedure

Step 1 Choose Devices > NAT .

Step 2 Click the edit icon ( ) next to the NAT policy you want to modify.

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

Step 3 Click Add Rule.

Step 4 Enter a Name for the rule.
Step 5 Specify a Type for the rule.
Step 6 Click the tab for the type of condition you want to add to the rule.
Step 7 Take any of the following actions:
• To choose available conditions to add to a list of selected conditions, click the available condition.
• To choose all listed available conditions, right-click the row for any available condition, then click Select
All.
• To choose a list of available conditions or filters, click inside the Search field and enter a search string.
The list updates as you type to display matching items.
You can search on object names and on the values configured for objects. For example, if you have an
individual network object named Texas Office with the configured value 192.168.3.0/24, and the
object is included in the group object US Offices, you can display both objects by entering a partial or
complete search string such as Tex, or by entering a value such as 3.

• To clear a search when searching available conditions or filters, click the reload icon ( ) above the
Search field or the clear icon ( ) in the Search field.
• To add selected zone conditions from a list of available conditions to a list of selected source or destination
conditions, click Add to Source or Add to Destination.
• To add selected network and port conditions from a list of available conditions to a list of selected original
or translated conditions, click Add to Original or Add to Translated.
• To drag and drop selected available conditions into a list of selected conditions, click a selected condition,
then drag and drop into the list of selected conditions.
• To add a literal condition to a list of selected conditions using a literal field, click to remove the prompt
from the literal field, enter the literal condition, and click Add. Network conditions provide a field for
adding literal conditions.
• To add a literal condition to a list of selected conditions using a drop-down list, choose a condition from
the drop-down list, then click Add. Port conditions provide a drop-down list for adding literal conditions.
• To add an individual object or condition filter so you can then choose it from the list of available
conditions, click the add icon ( ).
• To delete a single condition from a list of selected conditions, click the delete icon ( ) next to the
condition.

Firepower Management Center Configuration Guide, Version 6.3

1160
 Network Address Translation (NAT)
Literal Conditions in NAT Rules

• To delete a condition from a list of selected conditions, right-click to highlight the row for a selected
condition, then click Delete.

Step 8 Click Add to save your configuration.

Literal Conditions in NAT Rules

You can add a literal value to the list of original and translated conditions for the following condition types:
• Networks
• Ports

For network conditions, you type the literal value in a configuration field below the list of original or translated
conditions.
In the case of port conditions, you choose a protocol from a drop-down list. When the protocol is All, or TCP
or UDP, you enter a port number in a configuration field.
Each relevant conditions page provides the controls needed to add literal values. Values you enter in a
configuration field appear as red text if the value is invalid, or until it is recognized as valid. Values change
to blue text as you type when they are recognized as valid. A grayed Add button activates when a valid value
is recognized. Literal values you add appear immediately in the list of selected conditions.

Note The system builds a separate network map for each leaf domain. In a multi-domain 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.

Objects in NAT Rule Conditions

Objects that you create in the object manager (Objects > Object Management) are immediately available
for you to select from relevant lists of available NAT rule conditions.
You can also create objects on-the-fly from the NAT policy. A control on relevant conditions pages provides
access to the same configuration controls that you use in the object manager.
Individual objects created on-the-fly appear immediately in the list of available objects. You can add them to
the current rule, and to other existing and future rules. On the relevant conditions page, and also on the policy
Edit page, you can hover your pointer over an individual object to display the contents of the object, and over
a group object to display the number of individual objects in the group.

Zone Conditions in NAT Rules

The security zones on your system are comprised of interfaces on your managed devices. Zones that you add
to a NAT rule target the rule to devices on your network that have routed or hybrid interfaces in those zones.
You can only add security zones with routed or hybrid interfaces as conditions for NAT rules.
You can add either zones or standalone interfaces that are currently assigned to a virtual router to NAT rules.
If there are devices with un-deployed device configurations, the Zones page displays a warning icon ( ) at

Firepower Management Center Configuration Guide, Version 6.3

1161
 Network Address Translation (NAT)
Adding Zone Conditions to NAT Rules

the top of the available zones list, indicating that only deployed zones and interfaces are displayed. You can
click the arrow icon ( ) next to a zone to collapse or expand the zone to hide or view its interfaces.
If an interface is on a 7000 or 8000 Series device in a high-availability pair, the available zones list displays
an additional branch from that interface with the other interfaces in the high-availability pair as children of
the primary interface on the active device in the high-availability pair. You can also click the arrow icon ( )
to collapse or expand the paired device interfaces to hide or view its interfaces.

Note You can save and deploy policies with disabled interfaces, but the rules cannot provide any translation until
the interfaces are enabled.

The two lists on the right are the source and destination zones used for matching purposes by the NAT rules.
If the rule already has values configured, these lists display the existing values when you edit the rule. If the
source zones list is empty, the rule matches traffic from any zone or interface. If the destination zones list is
empty, the rule matches traffic to any zone or interface.
The system displays warnings for rules with zone combinations that never trigger on a targeted device.

Note You can save and deploy policies with these zone combinations, but the rules will not provide any translation.

You can add individual interfaces by selecting an item in a zone or by selecting a standalone interface. You
can only add interfaces in a zone if the zone it is assigned to has not already been added to a source zones or
destination zones list. These individually selected interfaces are not affected by changes to zones, even if you
remove them and add them to a different zone. If an interface is the primary member of a high-availability
pair and you are configuring a dynamic rule, you can add only the primary interface to the source zones or
destination zones list. For static rules, you can add individual high-availability pair member interfaces to the
source zones list. You can only add a primary high-availability pair interface to a list if none of its children
have been added, and you can only add individual high-availability pair interfaces if the primary has not been
added.
If you add a zone, the rule uses all interfaces associated with the zone. If you add or remove an interface from
the zone, the rule will not use the updated version of the zone until the device configuration has been re-deployed
to the devices where the interfaces reside.

Note In a static NAT rule, you can add only source zones. In a dynamic NAT rule, you can add both source and
destination zones.

Adding Zone Conditions to NAT Rules

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Any Admin/Network

Admin

Firepower Management Center Configuration Guide, Version 6.3

1162
 Network Address Translation (NAT)
Source Network Conditions in Dynamic NAT Rules

Procedure

Step 1 Choose Devices > NAT .

Step 2 Click the edit icon ( ) next to the NAT policy you want to modify.

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

Step 3 Click Add Rule.

Step 4 Enter a Name for the rule.
Step 5 Specify a Type for the rule.
Step 6 Click the Zones tab.
Step 7 Click a zone or interface in the Available Zones list.
Step 8 You have the following choices:
• To match traffic by source zone, click Add to Source.
• To match traffic by destination zone, click Add to Destination.
Note You can add only source zones to static NAT rules. Additionally, while you can add disabled
interfaces to a NAT rule, the rule does not provide any translation.

Step 9 Click Add to save the new rule.

Step 10 Click Save to save the changed policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Source Network Conditions in Dynamic NAT Rules

You configure the matching values and translation values of the source IP address for packets. If the original
source network is not configured, then any source IP address matches the dynamic NAT rule. Note that you
cannot configure source networks for static NAT rules. If a packet matches the NAT rule, the system uses the
values in the translated source network to assign the new value for the source IP address. For dynamic rules,
you must configure a translated source network with at least one value.

Caution If a network object or object group is being used by a NAT rule, and you change or delete the object or group,
it can cause the rule to become invalid.

You can add any of the following kinds of source network conditions to a dynamic NAT rule:
• individual and group network objects that you have created using the object manager
• individual network objects that you add from the Source Network conditions page, and can then add to
your rule and to other existing and future rules

Firepower Management Center Configuration Guide, Version 6.3

1163
 Network Address Translation (NAT)
Adding Network Conditions to a Dynamic NAT Rule

• literal, single IP addresses, ranges, or address blocks

Note The system builds a separate network map for each leaf domain. In a multi-domain 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.

Adding Network Conditions to a Dynamic NAT Rule

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Any Admin/Network

Admin

When you update the network conditions in a dynamic rule in use in a deployed policy, the system drops any
network sessions using the existing translated address pool.

Procedure

Step 1 Choose Devices > NAT .

Step 2 Click the edit icon ( ) next to the NAT policy you want to modify.

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

Step 3 Click Add Rule.

Step 4 Enter a Name for the rule.
Step 5 Specify a dynamic Type for the rule:
• Dynamic IP Only
• Dynamic IP + Port

Step 6 Click the Source Networks tab.

Step 7 Optionally, add an individual network object to the Available Networks list by clicking the add icon ( )
above the list.
You can add multiple IP addresses, CIDR blocks, and prefix lengths to each network object.

Step 8 Click a condition in the Available Networks list.

Step 9 You have the following choices:
• To match traffic by original source network, click Add to Original.
• To specify the translation value for traffic that matches the translated source network, click Add to
Translated.

Step 10 To add a literal IP address, range, or address block:

a) Click the Enter an IP address prompt below the Original Source Network or Translated Source
Network list.

Firepower Management Center Configuration Guide, Version 6.3

1164
 Network Address Translation (NAT)
Destination Network Conditions in NAT Rules

b) Enter an IP address, range, or address block.

You add ranges in the following format: lower IP address-upper IP address. For example:
179.13.1.1-179.13.1.10.

Note The system builds a separate network map for each leaf domain. In a multi-domain 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.

c) Click Add next to the value you entered.

Step 11 Click Add to save the rule.
Step 12 Click Save to save the changed policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Destination Network Conditions in NAT Rules

You configure the matching values and translation values of the destination IP address for packets. Note that
you cannot configure translated destination networks for dynamic NAT rules.
Because static NAT rules are one-to-one translations, the Available Networks list contains only network
objects and groups that contain only a single IP address. For static translations, you can add only a single
object or literal value to both the Original Destination Network or Translated Destination Network lists.

Caution If a network object or object group is being used by a NAT rule, and you change or delete the object or group,
it can cause the rule to become invalid.

You can add any of the following kinds of destination network conditions to a NAT rule:
• individual and group network objects that you have created using the object manager
• individual network objects that you add from the Destination Network conditions page, and can then add
to your rule and to other existing and future rules
• literal, single IP addresses, range, or address blocks
For static NAT rules, you can add only a CIDR with subnet mask /32, and only if there is not already a
value in the list.

Note The system builds a separate network map for each leaf domain. In a multi-domain 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.

Firepower Management Center Configuration Guide, Version 6.3

1165
 Network Address Translation (NAT)
Adding Destination Network Conditions to NAT Rules

Adding Destination Network Conditions to NAT Rules

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Any Admin/Network

Admin

When you update the network conditions in a dynamic rule in use in a deployed policy, the system drops any
network sessions using the existing translated address pool.

Procedure

Step 1 Choose Devices > NAT .

Step 2 Click the edit icon ( ) next to the NAT policy you want to modify.

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

Step 3 Click Add Rule.

Step 4 Enter a Name for the rule.
Step 5 Specify a Type for the rule.
Step 6 Click the Destination Network tab.

Step 7 Optionally, add an individual network object to the Available Networks list by clicking the add icon ( )
above the list.
For dynamic rules, you can add multiple IP addresses, CIDR blocks, and prefix lengths to each network object.
For static rules, you can add only a single IP address.

Step 8 Click a condition or object in the Available Networks list.

Step 9 You have the following choices:
• To match traffic by original destination network, click Add to Original.
• To specify the translation value for traffic that matches the translated destination network, click Add to
Translated.

Step 10 Optionally, click the Enter an IP address prompt below the Original Destination Network or Translated
Destination Network list, enter an IP address or address block, and click Add.
Step 11 Click Add.
Step 12 Click Save to save the changes to the policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1166
 Network Address Translation (NAT)
Port Conditions in NAT Rules

Port Conditions in NAT Rules

You can add a port condition to a rule to match network traffic based on the original and translated destination
port and transport protocol for translation. If the original port is not configured, any destination port matches
the rule. If a packet matches the NAT rule and a translated destination port is configured, the system translates
the port into that value. Note that for dynamic rules, you can specify only the original destination port. For
static rules, you can define a translated destination port, but only with an object with the same protocol as the
original destination port object or literal value.
The system matches the destination port against the value of the port object or literal port in the original
destination port list for static rules, or multiple values for dynamic rules.
Because static NAT rules are one-to-one translations, the Available Ports list contains only port objects and
groups that contain only a single port. For static translations, you can add only a single object or literal value
to both the Original Port or Translated Port lists.
For dynamic rules, you can add a range of ports. For example, when specifying the original destination port,
you can add 1000-1100 as a literal value.

Caution If a port object or object group is being used by a NAT rule, and you change or delete the object or group, it
can cause the rule to become invalid.

You can add any of the following kinds of port conditions to a NAT rule:
• individual and group port objects that you have created using the object manager
• individual port objects that you add from the Destination Ports conditions page, and can then add to your
rule and to other existing and future rules
• literal port values, consisting of a TCP, UDP, or All (TCP and UDP) transport protocol and a port

Adding Port Conditions to NAT Rules

Smart License Classic License Supported Devices Supported Domains Access

N/A Control 7000 & 8000 Series Any Admin/Network

Admin

Procedure

Step 1 Choose Devices > NAT .

Step 2 Click the edit icon ( ) next to the NAT policy you want to modify.

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

Step 3 Click Add Rule.

Step 4 Enter a Name for the rule.
Step 5 Specify a Type for the rule.

Firepower Management Center Configuration Guide, Version 6.3

1167
 Network Address Translation (NAT)
Adding Port Conditions to NAT Rules

Step 6 Click the Destination Port tab.

Step 7 Optionally, add an individual port object to the Available Ports list by clicking the add icon ( ) above the
list.
You can identify a single port or a port range in each port object that you add. You can then choose objects
you added as conditions for your rule. For static rules, you can use only port objects with single ports.

Step 8 Click a condition in the Available Ports list.

Step 9 You have the following choices:
• Click Add to Original.
• Click Add to Translated.
• Drag and drop available ports into a list.

Step 10 To add a literal port:

a) Choose an entry from the Protocol drop-down list beneath the Original Port or Translated Port lists.
b) Enter a port.
c) Click Add.
For dynamic rules, you can specify a single port or a range.

Step 11 Click Add.

Step 12 Click Save to save the changes to the policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1168
 CHAPTER 56
Network Address Translation (NAT) for
Firepower Threat Defense
The following topics explain Network Address Translation (NAT) and how to configure it on Firepower
Threat Defense devices.
• Why Use NAT?, on page 1169
• NAT Basics, on page 1170
• Guidelines for NAT, on page 1177
• Configure NAT for Threat Defense, on page 1182
• Translating IPv6 Networks, on page 1217
• Monitoring NAT, on page 1226
• Examples for NAT, on page 1226
• History for FTD NAT, on page 1265

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.

Firepower Management Center Configuration Guide, Version 6.3

1169
 Network Address Translation (NAT)
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) (Version 9.0(1) and later)—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:

Firepower Management Center Configuration Guide, Version 6.3

1170
 Network Address Translation (NAT)
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 1186.
• 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 1191.
• Static NAT—A consistent mapping between a real and mapped IP address. Allows bidirectional traffic
initiation. See Static NAT, on page 1198.
• 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 1207.

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 28: 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.

Firepower Management Center Configuration Guide, Version 6.3

1171
 Network Address Translation (NAT)
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 29: 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.

Firepower Management Center Configuration Guide, Version 6.3

1172
 Network Address Translation (NAT)
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.

Firepower Management Center Configuration Guide, Version 6.3

1173
 Network Address Translation (NAT)
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.

Table 86: 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.

Firepower Management Center Configuration Guide, Version 6.3

1174
Network Address Translation (NAT)
NAT Rule Order

Table Section Rule Type Order of Rules within the Section

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

Firepower Management Center Configuration Guide, Version 6.3

1175
 Network Address Translation (NAT)
NAT Interfaces

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 30: 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.

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

Firepower Management Center Configuration Guide, Version 6.3

1176
 Network Address Translation (NAT)
Addresses on a Unique Network

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.
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.

Firepower Management Center Configuration Guide, Version 6.3

1177
 Network Address Translation (NAT)
Firewall Mode Guidelines for 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.
• 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 Recommendations

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:

Firepower Management Center Configuration Guide, Version 6.3

1178
 Network Address Translation (NAT)
NAT Support for Inspected Protocols

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

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 87: NAT Supported Application Inspection

Application Inspected Protocol, Port NAT Limitations Pinholes Created

DCERPC TCP/135 No NAT64. Yes

Firepower Management Center Configuration Guide, Version 6.3

1179
 Network Address Translation (NAT)
NAT Support for Inspected Protocols

Application Inspected Protocol, Port NAT Limitations Pinholes Created

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.
(Clustering) No static PAT.

RTSP TCP/554 No extended PAT. Yes

(No handling for HTTP No NAT64.
cloaking.)
(Clustering) No static PAT.

SIP TCP/5060 No extended PAT. Yes

UDP/5060 No NAT64 or NAT46.
(Clustering) No static PAT.

Skinny (SCCP) TCP/2000 No extended PAT. Yes

No NAT64, NAT46, or NAT66.
(Clustering) No static PAT.

SQL*Net TCP/1521 No extended PAT. Yes

(versions 1, 2) No NAT64.
(Clustering) No static PAT.

Firepower Management Center Configuration Guide, Version 6.3

1180
 Network Address Translation (NAT)
Additional Guidelines for NAT

Application Inspected Protocol, Port NAT Limitations Pinholes Created

Sun RPC TCP/111 No extended PAT. Yes

UDP/111 No NAT64.

TFTP UDP/69 No NAT64. Yes

(Clustering) No static PAT.
Payload IP addresses are not translated.

XDMCP UDP/177 No extended PAT. Yes

No NAT64.
(Clustering) No static PAT.

Additional Guidelines for NAT

• 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.
• (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.
• 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.

Note If you remove a dynamic NAT or PAT rule, and then add a new rule with mapped
addresses that overlap the addresses in the removed rule, then the new rule will
not be used until all connections associated with the removed rule time out or are
cleared using the clear xlate command. This safeguard ensures that the same
address is not assigned to multiple hosts.

• You cannot use an object group with both IPv4 and IPv6 addresses; the object group must include only
one type of address.
• (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

Firepower Management Center Configuration Guide, Version 6.3

1181
 Network Address Translation (NAT)
Configure NAT for Threat Defense

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

Configure NAT for Threat Defense

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

1182
Network Address Translation (NAT)
Configure NAT for Threat Defense

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 the Policy Assignments
link.

• Click the the edit icon ( ) 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 1170.

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 1173.

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 1184.

Step 5 Create the rules as explained in the following sections.

• Dynamic NAT, on page 1186
• Dynamic PAT, on page 1191
• Static NAT, on page 1198
• Identity NAT, on page 1207

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.

Firepower Management Center Configuration Guide, Version 6.3

1183
 Network Address Translation (NAT)
Customizing NAT Rules for Multiple Devices

• To edit a rule, click the edit icon ( ) for the rule.

• To delete a rule, click the delete icon ( ) for the rule.

Step 7 Click Save.

You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you
deploy them.

Customizing NAT Rules for Multiple Devices

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
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.
a) Choose Objects > Object Management.
b) Select Interface Objects from the table of contents and click Add > Security Zone. (You can use interface
groups instead of zones.)
c) Configure the inside zone properties.
• Name—Enter a name, for example, inside-zone.
• Type—Select Routed for routed-mode devices, Switched for transparent mode.
• Selected Interfaces—Add the FTD-A/inside and FTD-B/inside interfaces to the selected list.

d) Click Save.
e) Click Add > Security Zone and define the outside zone properties.
• Name—Enter a name, for example, outside-zone.

Firepower Management Center Configuration Guide, Version 6.3

1184
Network Address Translation (NAT)
Customizing NAT Rules for Multiple Devices

• Type—Select Routed for routed-mode devices, Switched for transparent mode.

• Selected Interfaces—Add the FTD-A/outside and FTD-B/outside interfaces to the selected list.

f) Click Save.
Step 2 Create the network object for the original inside network on the Object Management page.
a) Select Network from the table of contents and click Add Network > Add Object.
b) Configure the inside network properties.
• Name—Enter a name, for example, inside-network.
• Network—Enter the network address, for example, 192.168.1.0/24.

c) Click Save.
Step 3 Create the network object for the translated NAT pool and define overrides.
a) Click Add Network > Add Object.
b) Configure the NAT pool properties for FTD-A.
• Name—Enter a name, for example, NAT-pool.
• Network—Enter the range of addresses to include in the pool for FTD-A, for example,
10.100.10.10-10.100.10.200.

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 the Override tab 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 a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Dynamic.

d) On the Interface Objects tab, 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.

Firepower Management Center Configuration Guide, Version 6.3

1185
 Network Address Translation (NAT)
Dynamic NAT

e) On the Translation tab, 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.

Dynamic NAT
The following topics explain dynamic NAT and how to configure it.

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 31: 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.

Firepower Management Center Configuration Guide, Version 6.3

1186
 Network Address Translation (NAT)
Dynamic NAT Disadvantages and Advantages

Figure 32: 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

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

Use dynamic auto NAT rules to translate addresses to different IP addresses that are routable on the destination
network.

Firepower Management Center Configuration Guide, Version 6.3

1187
 Network Address Translation (NAT)
Configure Dynamic Auto NAT

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.
• 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 a FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing 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.
• Type—Select Dynamic.

Step 4 On the Interface Objects tab, 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 the Translation tab, 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 the Advanced tab, 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 1252.
• 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

Firepower Management Center Configuration Guide, Version 6.3

1188
 Network Address Translation (NAT)
Configure Dynamic Manual NAT

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.

Configure Dynamic Manual NAT

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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

Step 1 Select Devices > NAT and create or edit a FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing rule.
The right click menu also has options to cut, copy, paste, insert, and delete rules.

Step 3 Configure the basic rule options:

Firepower Management Center Configuration Guide, Version 6.3

1189
 Network Address Translation (NAT)
Configure Dynamic Manual NAT

• NAT Rule—Select Manual NAT Rule.

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

Step 4 On the Interface Objects tab, 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 the Translation tab.) 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.

Firepower Management Center Configuration Guide, Version 6.3

1190
 Network Address Translation (NAT)
Dynamic PAT

Dynamic NAT does not support port translation, so leave the Original Source Port and Translated Source
Port fields empty. However, because the destination translation is always static, you can perform port translation
for the destination port.
NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and mapped service
objects are identical (both TCP or both UDP). For identity NAT, you can use the same service object for both
the real and mapped ports.

Step 8 (Optional.) On the Advanced tab, select the desired options:

• (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
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 1252.
• 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 9 Click Save to add the rule.

Step 10 Click Save on the NAT page to save your changes.

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. If available, the real source port number is used for
the mapped port. However, 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: 0 to 511, 512 to 1023, and 1024 to 65535. Therefore, ports below
1024 have only a small PAT pool that can be used. If you have a lot of traffic that uses the lower port ranges,
you can specify a flat range of ports to be used instead of the three unequal-sized tiers.
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.

Firepower Management Center Configuration Guide, Version 6.3

1191
 Network Address Translation (NAT)
Dynamic PAT Disadvantages and Advantages

Figure 33: 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.

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 1179.
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

• If available, the real source port number is used for the mapped port. However, 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:
0 to 511, 512 to 1023, and 1024 to 65535. Therefore, ports below 1024 have only a small PAT pool that
can be used. If you have a lot of traffic that uses the lower port ranges, you can specify a flat range of
ports to be used instead of the three unequal-sized tiers: either 1024 to 65535, or 1 to 65535.
• 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 and a flat range, then the other rule must also
specify extended PAT and a flat range.

Firepower Management Center Configuration Guide, Version 6.3

1192
 Network Address Translation (NAT)
Configure Dynamic Auto 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.

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.

Configure Dynamic Auto PAT

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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

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

Firepower Management Center Configuration Guide, Version 6.3

1193
 Network Address Translation (NAT)
Configure Dynamic Auto PAT

• 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

Step 1 Select Devices > NAT and create or edit a FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing 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.
• Type—Select Dynamic.

Step 4 On the Interface Objects tab, 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 the Translation tab, configure the following options:

• Original Source—The network object that contains the addresses you are translating.
• 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 the Advanced tab. 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 tab 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

Firepower Management Center Configuration Guide, Version 6.3

1194
 Network Address Translation (NAT)
Configure Dynamic Manual PAT

used. The round-robin method assigns one address/port from each PAT address in the pool before
returning to use the first address again, and then the second address, and so on.
• Extended PAT Table—To use extended PAT. Extended PAT uses 65535 ports per service, as
opposed to per IP address, by including the destination address and port in the translation information.
Normally, the destination port and address are not considered when creating PAT translations, so
you are limited to 65535 ports per PAT address. For example, with extended PAT, you can create a
translation of 10.1.1.1:1027 when going to 192.168.1.7:23 as well as a translation of 10.1.1.1:1027
when going to 192.168.1.7:80. You cannot use this option with interface PAT or interface PAT
fallback.
• Flat Port Range, Include Reserved Ports—To use the 1024 to 65535 port range as a single flat
range when allocating TCP/UDP ports. When choosing the mapped port number for a translation,
PAT uses the real source port number if it is available. However, without this option, if the real port
is not available, by default the mapped ports are chosen from the same range of ports as the real port
number: 1 to 511, 512 to 1023, and 1024 to 65535. To avoid running out of ports at the low ranges,
configure this setting. To use the entire range of 1 to 65535, also check the Include Reserved Ports
option.

Step 7 (Optional.) On the Advanced tab, select the desired options:

• 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. You cannot select
this option if you already configured interface PAT as the translated address or PAT pool.
• IPv6—Whether to use the IPv6 address of the destination interface for interface PAT.

Step 8 Click Save to add the rule.

Step 9 Click Save on the NAT page to save your changes.

Configure Dynamic Manual PAT

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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

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:

Firepower Management Center Configuration Guide, Version 6.3

1195
 Network Address Translation (NAT)
Configure Dynamic Manual PAT

• 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—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.

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

Step 1 Select Devices > NAT and create or edit a FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing 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 Manual NAT Rule.
• 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.

Step 4 On the Interface Objects tab, 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 the Translation tab.) 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.

Firepower Management Center Configuration Guide, Version 6.3

1196
Network Address Translation (NAT)
Configure Dynamic Manual PAT

• Original Source—The network object or group that contains the addresses you are translating.
• Original Destination—(Optional.) The network object that contains the addresses of the destinations.
If you leave this blank, the source address translation applies regardless of destination. If you do specify
the destination address, you can configure a static translation for that address or just use identity NAT
for it.
You can select Source Interface IP to base the original destination on the source interface (which cannot
be Any). If you select this option, you must also select a translated destination object. To implement a
static interface NAT with port translation for the destination addresses, select this option and also select
the appropriate port objects for the destination ports.

Step 6 Identify the translated packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on
the destination interface network. You can translate between IPv4 and IPv6 if desired.
• Translated Source—One of the following:
• (Interface PAT.) To use the address of the destination interface, select Destination Interface IP.
You must also select a specific destination interface object. To use the IPv6 address of the interface,
you must also select the IPv6 option on the Advanced tab. Skip the step for configuring a PAT
pool.
• To use a single address other than the destination interface address, select the host network object
you created for this purpose. Skip the step for configuring a PAT pool.
• To use a PAT pool, leave Translated Source empty.

• Translated Destination—(Optional.) The network object or group that contains the destination addresses
used in the translated packet. If you selected an object for Original Destination, you can set up identity
NAT (that is, no translation) by selecting the same object.

Step 7 (Optional.) Identify the destination service ports for service translation: Original Destination Port, Translated
Destination Port.
Dynamic NAT does not support port translation, so leave the Original Source Port and Translated Source
Port fields empty. However, because the destination translation is always static, you can perform port translation
for the destination port.
NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and mapped service
objects are identical (both TCP or both UDP). For identity NAT, you can use the same service object for both
the real and mapped ports.

Step 8 If you are using a PAT pool, select the PAT Pool tab 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.

Firepower Management Center Configuration Guide, Version 6.3

1197
 Network Address Translation (NAT)
Static NAT

You can alternatively select Destination Interface IP, which is another way to implement interface PAT.
c) (Optional) Select the following options as needed:
• Use Round Robin Allocation—To assign addresses/ports in a round-robin fashion. By default
without round robin, all ports for a PAT address will be allocated before the next PAT address is
used. The round-robin method assigns one address/port from each PAT address in the pool before
returning to use the first address again, and then the second address, and so on.
• Extended PAT Table—To use extended PAT. Extended PAT uses 65535 ports per service, as
opposed to per IP address, by including the destination address and port in the translation information.
Normally, the destination port and address are not considered when creating PAT translations, so
you are limited to 65535 ports per PAT address. For example, with extended PAT, you can create a
translation of 10.1.1.1:1027 when going to 192.168.1.7:23 as well as a translation of 10.1.1.1:1027
when going to 192.168.1.7:80. You cannot use this option with interface PAT or interface PAT
fallback.
• Flat Port Range, Include Reserved Ports—To use the 1024 to 65535 port range as a single flat
range when allocating TCP/UDP ports. When choosing the mapped port number for a translation,
PAT uses the real source port number if it is available. However, without this option, if the real port
is not available, by default the mapped ports are chosen from the same range of ports as the real port
number: 1 to 511, 512 to 1023, and 1024 to 65535. To avoid running out of ports at the low ranges,
configure this setting. To use the entire range of 1 to 65535, also check the Include Reserved Ports
option.

Step 9 (Optional.) On the Advanced tab, select the desired options:

• 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 10 Click Save to add the rule.

Step 11 Click Save on the NAT page to save your changes.

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.

Firepower Management Center Configuration Guide, Version 6.3

1198
 Network Address Translation (NAT)
Static NAT with Port Translation

Figure 34: 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 35: 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.

Firepower Management Center Configuration Guide, Version 6.3

1199
 Network Address Translation (NAT)
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 36: 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.

Firepower Management Center Configuration Guide, Version 6.3

1200
 Network Address Translation (NAT)
Other Mapping Scenarios (Not Recommended)

Figure 37: 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.

Firepower Management Center Configuration Guide, Version 6.3

1201
 Network Address Translation (NAT)
Configure Static Auto NAT

Figure 38: 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 39: 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.

Configure Static Auto NAT

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

1202
Network Address Translation (NAT)
Configure Static Auto NAT

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.
• Translated Source—You have the following options to specify the translated address:
• Destination Interface—To use the destination interface address, you do not need a network object.
This configures static interface NAT with port translation: the source address/port is translated to
the interface's address and the same port number.
• Address—Create a network object or group containing hosts, ranges, or subnets. A group cannot
contain both IPv4 and IPv6 addresses; it must contain one type only. Typically, you configure the
same number of mapped addresses as real addresses for a one-to-one mapping. You can, however,
have a mismatched number of addresses.

Procedure

Step 1 Select Devices > NAT and create or edit a FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing 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.
• Type—Select Static.

Step 4 On the Interface Objects tab, 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 the Translation tab, configure the following options:

• Original Source—The network object that contains the addresses you are translating.
• Translated Source—One of the following:
• To use a set group of addresses, select Address and the network object or group that contains the
mapped addresses. Typically, you configure the same number of mapped addresses as real addresses
for a one-to-one mapping. You can, however, have a mismatched number of addresses.
• (Static interface NAT with port translation.) To use the address of the destination interface, select
Destination Interface IP. You must also select a specific destination interface object. To use the

Firepower Management Center Configuration Guide, Version 6.3

1203
 Network Address Translation (NAT)
Configure Static Manual NAT

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.

• (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.

Step 6 (Optional.) On the Advanced tab, 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 1252. This option is not available if you are doing port
translation.
• IPv6—Whether to use the IPv6 address of the destination interface for interface PAT.
• Net to Net Mapping—For NAT 46, select this option to translate the first IPv4 address to the first IPv6
address, the second to the second, and so on. Without this option, the IPv4-embedded method is used.
For a one-to-one translation, you must use this option.
• Do not proxy ARP on Destination Interface—Disables proxy ARP for incoming packets to the mapped
IP addresses. If you use addresses on the same network as the mapped interface, the system uses proxy
ARP to answer any ARP requests for the mapped addresses, thus intercepting traffic destined for a
mapped address. This solution simplifies routing because the device does not have to be the gateway for
any additional networks. You can disable proxy ARP if desired, in which case you need to be sure to
have proper routes on the upstream router. Normally for identity NAT, proxy ARP is not required, and
in some cases can cause connectivity issues.

Step 7 Click Save to add the rule.

Step 8 Click Save on the NAT page to save your changes.

Configure Static Manual NAT

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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

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:

Firepower Management Center Configuration Guide, Version 6.3

1204
Network Address Translation (NAT)
Configure Static Manual NAT

• 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—You have the following options to specify the translated address:
• Destination Interface—To use the destination interface address, you do not need a network object.
This configures static interface NAT with port translation: the source address/port is translated to
the interface's address and the same port number.
• Address—Create a network object or group containing hosts, 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.

You can also create network objects for the Original Destination and Translated Destination if you are
configuring a static translation for those addresses in the rule. If you want to configure destination static
interface NAT with port translation only, you can skip adding an object for the destination mapped addresses
and specify the interface in the rule.
You can also perform port translation on the source, destination, or both. In the Object Manager, ensure that
there are port objects you can use for the original and translated ports.

Procedure

Step 1 Select Devices > NAT and create or edit a FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing 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 Manual NAT Rule.
• 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.
• Enable—Whether you want the rule to be active. You can later activate or deactivate the rule using the
right-click menu on the rules page.
• Insert—Where you want to add the rule. You can insert it in a category (before or after auto NAT rules),
or above or below the rule number you specify.

Step 4 On the Interface Objects tab, 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 the Translation tab.) Identify the original packet addresses, either IPv4 or IPv6; namely, the packet
addresses as they appear in the original packet.

Firepower Management Center Configuration Guide, Version 6.3

1205
 Network Address Translation (NAT)
Configure Static Manual NAT

See the following figure for an example of the original packet vs. the translated packet.

• Original Source—The network object or group that contains the addresses you are translating.
• Original Destination—(Optional.) The network object that contains the addresses of the destinations.
If you leave this blank, the source address translation applies regardless of destination. If you do specify
the destination address, you can configure a static translation for that address or just use identity NAT
for it.
You can select Source Interface IP to base the original destination on the source interface (which cannot
be Any). If you select this option, you must also select a translated destination object. To implement a
static interface NAT with port translation for the destination addresses, select this option and also select
the appropriate port objects for the destination ports.

Step 6 Identify the translated packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on
the destination interface network. You can translate between IPv4 and IPv6 if desired.
• Translated Source—One of the following:
• To use a set group of addresses, select Address and the network object or group that contains the
mapped addresses. Typically, you configure the same number of mapped addresses as real addresses
for a one-to-one mapping. You can, however, have a mismatched number of addresses.
• (Static interface NAT with port translation.) To use the address of the destination interface, select
Destination Interface IP. You must also select a specific destination interface object. To use the
IPv6 address of the interface, you must also select the IPv6 option on 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.

• Translated Destination—(Optional.) The network object or group that contains the destination addresses
used in the translated packet. If you selected an object for Original Destination, you can set up identity
NAT (that is, no translation) by selecting the same object.

Step 7 (Optional.) Identify the source or destination service ports for service translation.
If you are configuring static NAT with port translation, you can translate ports for the source, destination, or
both. For example, you can translate between TCP/80 and TCP/8080.
NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and mapped service
objects are identical (both TCP or both UDP). For identity NAT, you can use the same service object for both
the real and mapped ports.
• Original Source Port, Translated Source Port—Defines a port translation for the source address.
• Original Destination Port, Translated Destination Port—Defines a port translation for the destination
address.

Firepower Management Center Configuration Guide, Version 6.3

1206
 Network Address Translation (NAT)
Identity NAT

Step 8 (Optional.) On the Advanced tab, 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 1252. This option is not available if you are doing port
translation.
• IPv6—Whether to use the IPv6 address of the destination interface for interface PAT.
• Net to Net Mapping—For NAT 46, select this option to translate the first IPv4 address to the first IPv6
address, the second to the second, and so on. Without this option, the IPv4-embedded method is used.
For a one-to-one translation, you must use this option.
• Do not proxy ARP on Destination Interface—Disables proxy ARP for incoming packets to the mapped
IP addresses. If you use addresses on the same network as the mapped interface, the system uses proxy
ARP to answer any ARP requests for the mapped addresses, thus intercepting traffic destined for a
mapped address. This solution simplifies routing because the device does not have to be the gateway for
any additional networks. You can disable proxy ARP if desired, in which case you need to be sure to
have proper routes on the upstream router. Normally for identity NAT, proxy ARP is not required, and
in some cases can cause connectivity issues.
• Unidirectional—Select this option to prevent the destination addresses from initiating traffic to the
source addresses.

Step 9 Click Save to add the rule.

Step 10 Click Save on the NAT page to save your changes.

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 40: Identity NAT

The following topics explain how to configure identity NAT.

Firepower Management Center Configuration Guide, Version 6.3

1207
 Network Address Translation (NAT)
Configure Identity Auto NAT

Configure Identity Auto NAT

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

Use static identity auto NAT rules to prevent the translation of an address. That is, to translate the address to
itself.

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.
• Translated Source—A network object or group with the exact same contents as the original source
object. You can use the same object.

Procedure

Step 1 Select Devices > NAT and create or edit a FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing 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.
• Type—Select Static.

Step 4 On the Interface Objects tab, 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 the Translation tab, configure the following options:

• Original Source—The network object that contains the addresses you are translating.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

1208
 Network Address Translation (NAT)
Configure Identity Manual NAT

Step 6 (Optional.) On the Advanced tab, select the desired options:

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

Step 7 Click Save to add the rule.

Step 8 Click Save on the NAT page to save your changes.

Configure Identity Manual NAT

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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

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—The same object as the original source. Optionally, you can select a different object
that has the exact same contents.

You can also create network objects for the Original Destination and Translated Destination if you are
configuring a static translation for those addresses in the rule. If you want to configure destination static
interface NAT with port translation only, you can skip adding an object for the destination mapped addresses
and specify the interface in the rule.
You can also perform port translation on the source, destination, or both. In the Object Manager, ensure that
there are port objects you can use for the original and translated ports. You can use the same object for identity
NAT.

Firepower Management Center Configuration Guide, Version 6.3

1209
 Network Address Translation (NAT)
Configure Identity Manual NAT

Procedure

Step 1 Select Devices > NAT and create or edit a FTD NAT policy.
Step 2 Do one of the following:
• Click the Add Rule button to create a new rule.
• Click the edit icon ( ) to edit an existing 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 Manual NAT Rule.
• 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.
• Enable—Whether you want the rule to be active. You can later activate or deactivate the rule using the
right-click menu on the rules page.
• Insert—Where you want to add the rule. You can insert it in a category (before or after auto NAT rules),
or above or below the rule number you specify.

Step 4 On the Interface Objects tab, 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 Identify the original packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear in the
original packet.
See the following figure for an example of the original packet vs. the translated packet where you perform
identity NAT on the inside host but translate the outside host.

• Original Source—The network object or group that contains the addresses you are translating.
• Original Destination—(Optional.) The network object that contains the addresses of the destinations.
If you leave this blank, the source address translation applies regardless of destination. If you do specify
the destination address, you can configure a static translation for that address or just use identity NAT
for it.
You can select Interface Object to base the original destination on the source interface (which cannot
be Any). If you select this option, you must also select a translated destination object. To implement a

Firepower Management Center Configuration Guide, Version 6.3

1210
 Network Address Translation (NAT)
NAT Rule Properties for Firepower Threat Defense

static interface NAT with port translation for the destination addresses, select this option and also select
the appropriate port objects for the destination ports.

Step 6 Identify the translated packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on
the destination interface network. You can translate between IPv4 and IPv6 if desired.
• Translated Source—The same object as the original source. Optionally, you can select a different object
that has the exact same contents.
• Translated Destination—(Optional.) The network object or group that contains the destination addresses
used in the translated packet. If you selected an object for Original Destination, you can set up identity
NAT (that is, no translation) by selecting the same object.

Step 7 (Optional.) Identify the source or destination service ports for service translation.
If you are configuring static NAT with port translation, you can translate ports for the source, destination, or
both. For example, you can translate between TCP/80 and TCP/8080.
NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and mapped service
objects are identical (both TCP or both UDP). For identity NAT, you can use the same service object for both
the real and mapped ports.
• Original Source Port, Translated Source Port—Defines a port translation for the source address.
• Original Destination Port, Translated Destination Port—Defines a port translation for the destination
address.

Step 8 (Optional.) On the Advanced tab, select the desired options:

• Translate DNS replies that match this rule—Do not configure this option for identity NAT.
• IPv6—Whether to use the IPv6 address of the destination interface for interface PAT.
• 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.
• 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.

Step 9 Click Save to add the rule.

Step 10 Click Save on the NAT page to save your changes.

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

Firepower Management Center Configuration Guide, Version 6.3

1211
 Network Address Translation (NAT)
Interface Objects NAT Properties

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 1173.
Type
Whether the translation rule is Dynamic or Static. Dynamic translation automatically chooses the mapped
address from a pool of addresses, or an address/port combination when implementing PAT. Use static
translation if you want to precisely define the mapped address/port.
Enable (Manual NAT only.)
Whether you want the rule to be active. You can later activate or deactivate the rule using the right-click
menu on the rules page. You cannot disable auto NAT rules.
Insert (Manual NAT only.)
Where you want to add the rule. You can insert it in a category (before or after auto NAT rules), or above
or below the rule number you specify.
Description (Optional. Manual NAT only.)
A description of the purpose of the rule.
The following topics describe the tabs for the NAT rules properties.

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.

Firepower Management Center Configuration Guide, Version 6.3

1212
 Network Address Translation (NAT)
Translation Properties for Auto NAT

Translation Properties for Auto NAT

Use the options on the Translation tab 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.
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 the Advanced tab. 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.
• To use a PAT pool, leave Translated Source empty. Select the PAT pool object on the PAT
Pool tab.

• 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
that has the exact same contents.

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.

Firepower Management Center Configuration Guide, Version 6.3

1213
 Network Address Translation (NAT)
Translation Properties for Manual NAT

Translation Properties for Manual NAT

Use the options on the Translation tab 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 the Advanced tab. 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.
• To use a PAT pool, leave Translated Source empty. Select the PAT pool object on the PAT
Pool tab.

• 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
that has the exact same contents.

Original Destination
The network object that contains the addresses of the destinations. If you leave this blank, the source
address translation applies regardless of destination. If you do specify the destination address, you can
configure a static translation for that address or just use identity NAT for it.

Firepower Management Center Configuration Guide, Version 6.3

1214
 Network Address Translation (NAT)
PAT Pool NAT Properties

You can select Source Interface IP to base the original destination on the source interface (which cannot
be Any). If you select this option, you must also select a translated destination object. To implement a
static interface NAT with port translation for the destination addresses, select this option and also select
the appropriate port objects for the destination ports.
Translated Destination
The network object or group that contains the destination addresses used in the translated packet. If you
selected an object for Original Destination, you can set up identity NAT (that is, no translation) by
selecting the same object.
Original Source Port, Translated Source Port, Original Destination Port, Translated Destination Port
The port objects that define the source and destination services for the original and translated packets.
You can translate the ports, or select the same object to make the rule sensitive to the service without
translating the ports. Keep the following rules in mind when configuring services:
• (Dynamic NAT or PAT.) You cannot do translation on the Original Source Port and Translated
Source Port. You can do translation on the destination port only.
• NAT only supports TCP or UDP. When translating a port, be sure the protocols in the real and
mapped service objects are identical (both TCP or both UDP). For identity NAT, you can use the
same service object for both the real and mapped ports.

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.
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

Firepower Management Center Configuration Guide, Version 6.3

1215
 Network Address Translation (NAT)
Advanced NAT Properties

to 192.168.1.7:23 as well as a translation of 10.1.1.1:1027 when going to 192.168.1.7:80. You cannot

use this option with interface PAT or interface PAT fallback.
Flat Port Range; Include Reserved Ports
To use the 1024 to 65535 port range as a single flat range when allocating TCP/UDP ports. When choosing
the mapped port number for a translation, PAT uses the real source port number if it is available. However,
without this option, if the real port is not available, by default the mapped ports are chosen from the same
range of ports as the real port number: 1 to 511, 512 to 1023, and 1024 to 65535. To avoid running out
of ports at the low ranges, configure this setting. To use the entire range of 1 to 65535, also check the
Include Reserved Ports option.

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.
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
1252. 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.

Firepower Management Center Configuration Guide, Version 6.3

1216
 Network Address Translation (NAT)
Translating IPv6 Networks

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.

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:
• 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.

Firepower Management Center Configuration Guide, Version 6.3

1217
 Network Address Translation (NAT)
NAT64/46 Example: Inside IPv6 Network with Outside IPv4 Internet

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

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.)

Firepower Management Center Configuration Guide, Version 6.3

1218
Network Address Translation (NAT)
NAT64/46 Example: Inside IPv6 Network with Outside IPv4 Internet

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.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8::/96.

d) Click Save.
e) Click Add Network > Add Object and define the outside IPv4 network.
Name the network object (for example, outside_v4_any) and enter the network address 0.0.0.0/0.

Firepower Management Center Configuration Guide, Version 6.3

1219
 Network Address Translation (NAT)
NAT64/46 Example: Inside IPv6 Network with Outside IPv4 Internet

f) Click Save.
Step 2 Configure the NAT64 dynamic PAT rule for the inside IPv6 network.
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Dynamic.

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = outside.

e) On the Translation tab, configure the following:

• Original Source = inside_v6 network object.
• Translated Source = Destination Interface IP.

f) Click OK.
With this rule, any traffic from the 2001:db8::/96 subnet on the inside interface going to the outside
interface gets a NAT64 PAT translation using the IPv4 address of the outside interface.

Step 3 Configure the static NAT46 rule for the outside IPv4 network.
a) Click Add Rule.

Firepower Management Center Configuration Guide, Version 6.3

1220
 Network Address Translation (NAT)
NAT66: Translating IPv6 Addresses to Different IPv6 Addresses

b) Configure the following properties:

• NAT Rule = Auto NAT Rule.
• Type = Static.

c) On the Interface Objects tab, configure the following:

• Source Interface Objects = outside.
• Destination Interface Objects = inside.

d) On the Translation tab, configure the following:

• Original Source = outside_v4_any network object.
• Translated Source > Address = inside_v6 network object.

e) On the Advanced tab, select Translate DNS replies that match this rule.

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.

Firepower Management Center Configuration Guide, Version 6.3

1221
 Network Address Translation (NAT)
NAT66 Example, Static Translation between Networks

NAT66 Example, Static Translation between Networks

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

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 IPv6 NAT networks.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8:122:2091::/96.

Firepower Management Center Configuration Guide, Version 6.3

1222
Network Address Translation (NAT)
NAT66 Example, Static Translation between Networks

d) Click Save.
e) Click Add Network > Add Object and define the outside IPv6 NAT network.
Name the network object (for example, outside_nat_v6) and enter the network address
2001:db8:122:2999::/96.

f) Click Save.
Step 2 Configure the static NAT rule for the inside IPv6 network.
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = outside.

e) On the Translation tab, configure the following:

• Original Source = inside_v6 network object.
• Translated Source > Address = outside_nat_v6 network object.

Firepower Management Center Configuration Guide, Version 6.3

1223
 Network Address Translation (NAT)
NAT66 Example, Simple IPv6 Interface PAT

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.

NAT66 Example, Simple IPv6 Interface PAT

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

1224
Network Address Translation (NAT)
NAT66 Example, Simple IPv6 Interface PAT

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 object that defines the inside IPv6 network.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:db8:122:2091::/96.

d) Click Save.
Step 2 Configure the dynamic PAT rule for the inside IPv6 network.
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Dynamic.

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = outside.

e) On the Translation tab, configure the following:

• Original Source = inside_v6 network object.
• Translated Source = Destination Interface IP.

f) On the Advanced tab, select IPv6, which indicates that the IPv6 address of the destination interface should
be used.

Firepower Management Center Configuration Guide, Version 6.3

1225
 Network Address Translation (NAT)
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.

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)

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

1226
Network Address Translation (NAT)
Providing Access to an Inside Web Server (Static Auto NAT)

Figure 41: Static NAT for an Inside Web Server

Before you begin

Ensure that you have interface objects (security zones or interface groups) that contain the interfaces for the
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.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the web server’s private address.
Name the network object (for example, WebServerPrivate) and enter the real host IP address, 10.1.2.27.

Firepower Management Center Configuration Guide, Version 6.3

1227
 Network Address Translation (NAT)
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.
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = outside.

e) On the Translation tab, configure the following:

• Original Source = WebServerPrivate network object.
• Translated Source > Address= WebServerPublic network object.

f) Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1228
 Network Address Translation (NAT)
Dynamic Auto NAT for Inside Hosts and Static NAT for an Outside Web Server

Step 3 Click Save on the NAT rule page.

Dynamic Auto NAT for Inside Hosts and Static NAT for an Outside Web Server
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

The following example configures dynamic NAT for inside users on a private network when they access the
outside. Also, when inside users connect to an outside web server, that web server address is translated to an
address that appears to be on the inside network.
Figure 42: Dynamic NAT for Inside, Static NAT for Outside Web Server

Before you begin

Ensure that you have interface objects (security zones or interface groups) that contain the interfaces for the
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.

Firepower Management Center Configuration Guide, Version 6.3

1229
 Network Address Translation (NAT)
Dynamic Auto NAT for Inside Hosts and Static NAT for an Outside Web Server

Procedure

Step 1 Create a network object for the dynamic NAT pool to which you want to translate the inside addresses.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the dynamic NAT pool.
Name the network object (for example, myNATpool) and enter the network range
209.165.201.20-209.165.201.30.

d) Click Save.
Step 2 Create a network object for the inside network.
a) Click Add Network > Add Object.
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.
a) Click Add Network > Add Object.
b) Name the network object (for example, MyWebServer) and enter the host address 209.165.201.12.

Firepower Management Center Configuration Guide, Version 6.3

1230
Network Address Translation (NAT)
Dynamic Auto NAT for Inside Hosts and Static NAT for an Outside Web Server

c) Click Save.
Step 4 Create a network object for the translated web server address.
a) Click Add Network > Add Object.
b) Name the network object (for example, TransWebServer) and enter the host address 10.1.2.20.

c) Click Save.
Step 5 Configure dynamic NAT for the inside network using the dynamic NAT pool object.
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Dynamic.

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = outside.

e) On the Translation tab, configure the following:

• Original Source = myInsNet network object.
• Translated Source > Address= myNATpool network group.

f) Click Save.
Step 6 Configure static NAT for the web server.

Firepower Management Center Configuration Guide, Version 6.3

1231
 Network Address Translation (NAT)
Inside Load Balancer with Multiple Mapped Addresses (Static Auto NAT, One-to-Many)

a) Click Add Rule.

b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.

c) On the Interface Objects tab, configure the following:

• Source Interface Objects = outside.
• Destination Interface Objects = inside.

d) On the Translation tab, configure the following:

• Original Source = myWebServer network object.
• Translated Source > Address= TransWebServer network object.

e) Click Save.
Step 7 Click Save on the NAT rule page.

Inside Load Balancer with Multiple Mapped Addresses (Static Auto NAT,
One-to-Many)
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

1232
Network Address Translation (NAT)
Inside Load Balancer with Multiple Mapped Addresses (Static Auto NAT, One-to-Many)

Figure 43: Static NAT with One-to-Many for an Inside Load Balancer

Before you begin

Ensure that you have interface objects (security zones or interface groups) that contain the interfaces for the
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 a network object for the addresses to which you want to map the load balancer.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the addresses.
Name the network object (for example, myPublicIPs) and enter the network range
209.165.201.3-209.165.201.5.

Firepower Management Center Configuration Guide, Version 6.3

1233
 Network Address Translation (NAT)
Inside Load Balancer with Multiple Mapped Addresses (Static Auto NAT, One-to-Many)

d) Click Save.
Step 2 Create a network object for the load balancer.
a) Click Add Network > Add Object.
b) Name the network object (for example, myLBHost), enter the host address 10.1.2.27.

c) Click Save.
Step 3 Configure static NAT for the load balancer.
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = outside.

e) On the Translation tab, configure the following:

• Original Source = myLBHost network object.
• Translated Source > Address= myPublicIPs network group.

Firepower Management Center Configuration Guide, Version 6.3

1234
 Network Address Translation (NAT)
Single Address for FTP, HTTP, and SMTP (Static Auto NAT-with-Port-Translation)

f) Click Save.
Step 4 Click Save on the NAT rule page.

Single Address for FTP, HTTP, and SMTP (Static Auto

NAT-with-Port-Translation)
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

1235
 Network Address Translation (NAT)
Single Address for FTP, HTTP, and SMTP (Static Auto NAT-with-Port-Translation)

Figure 44: Static NAT-with-Port-Translation

Before you begin

Ensure that you have interface objects (security zones or interface groups) that contain the interfaces for the
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.

a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Name the network object (for example, FTPserver), and enter the real IP address for the FTP server,
10.1.2.27.

Firepower Management Center Configuration Guide, Version 6.3

1236
Network Address Translation (NAT)
Single Address for FTP, HTTP, and SMTP (Static Auto NAT-with-Port-Translation)

d) Click Save.
Step 2 Create a network object for the HTTP server.
a) Click Add Network > Add Object.
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.
a) Click Add Network > Add Object.
b) Name the network object (for example, SMTPserver), enter the host address 10.1.2.29.

c) Click Save.
Step 4 Create a network object for the public IP address used for the three servers.
a) Click Add Network > Add Object.
b) Name the network object (for example, ServerPublicIP) and enter the host address 209.165.201.3.

c) Click Save.
Step 5 Configure static NAT with port translation for the FTP server, mapping the FTP port to itself.
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.

Firepower Management Center Configuration Guide, Version 6.3

1237
 Network Address Translation (NAT)
Single Address for FTP, HTTP, and SMTP (Static Auto NAT-with-Port-Translation)

• Type = Static.

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = outside.

e) On the Translation tab, configure the following:

• 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.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.

c) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = outside.

d) On the Translation tab, configure the following:

• Original Source = HTTPserver network object.
• Translated Source > Address= ServerPublicIP network object.
• Original Port > TCP = 80.
• Translated Port = 80.

Firepower Management Center Configuration Guide, Version 6.3

1238
Network Address Translation (NAT)
Single Address for FTP, HTTP, and SMTP (Static Auto NAT-with-Port-Translation)

e) Click Save.
Step 7 Configure static NAT with port translation for the SMTP server, mapping the SMTP port to itself.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.

c) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = outside.

d) On the Translation tab, configure the following:

• Original Source = SMTPserver network object.
• Translated Source > Address= ServerPublicIP network object.
• Original Port > TCP = 25.
• Translated Port = 25.

e) Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1239
 Network Address Translation (NAT)
Different Translation Depending on the Destination (Dynamic Manual PAT)

Step 8 Click Save on the NAT rule page.

Different Translation Depending on the Destination (Dynamic Manual PAT)

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.
Figure 45: Manual NAT with Different Destination Addresses

Before you begin

Ensure that you have interface objects (security zones or interface groups) that contain the interfaces for the
device that protects the servers. In this example, we will assume the interface objects are security zones named
inside and dmz. To configure interface objects, select Objects > Object Management, then select Interface.

Procedure

Step 1 Create a network object for the inside network.

a) Choose Objects > Object Management.

Firepower Management Center Configuration Guide, Version 6.3

1240
Network Address Translation (NAT)
Different Translation Depending on the Destination (Dynamic Manual PAT)

b) Select Network from the table of contents and click Add Network > Add Object.
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.
a) Click Add Network > Add Object.
b) Name the network object (for example, DMZnetwork1) and enter the network address 209.165.201.0/27
(subnet mask of 255.255.255.224).

c) Click Save.
Step 3 Create a network object for the PAT address for DMZ network 1.
a) Click Add Network > Add Object.
b) Name the network object (for example, PATaddress1) and enter the host address 209.165.202.129.

c) Click Save.
Step 4 Create a network object for the DMZ network 2.
a) Click Add Network > Add Object.
b) Name the network object (for example, DMZnetwork2) and enter the network address 209.165.200.224/27
(subnet mask of 255.255.255.224).

Firepower Management Center Configuration Guide, Version 6.3

1241
 Network Address Translation (NAT)
Different Translation Depending on the Destination (Dynamic Manual PAT)

c) Click Save.
Step 5 Create a network object for the PAT address for DMZ network 2.
a) Click Add Network > Add Object.
b) Name the network object (for example, PATaddress2) and enter the host address 209.165.202.130.

c) Click Save.
Step 6 Configure dynamic manual PAT for DMZ network 1.
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = dmz.

e) On the Translation tab, configure the following:

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

Firepower Management Center Configuration Guide, Version 6.3

1242
Network Address Translation (NAT)
Different Translation Depending on the Destination (Dynamic Manual PAT)

f) Click Save.
Step 7 Configure dynamic manual PAT for DMZ network 2.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.

c) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = dmz.

d) On the Translation tab, configure the following:

• Original Source = myInsideNetwork network object.
• Translated Source > Address= PATaddress2 network object.
• Original Destination > Address = DMZnetwork2 network object.
• Translated Destination = DMZnetwork2 network object.

Firepower Management Center Configuration Guide, Version 6.3

1243
 Network Address Translation (NAT)
Different Translation Depending on the Destination Address and Port (Dynamic Manual PAT)

e) Click Save.
Step 8 Click Save on the NAT rule page.

Different Translation Depending on the Destination Address and Port (Dynamic

Manual PAT)
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.
Figure 46: Manual NAT with Different Destination Ports

Before you begin

Ensure that you have interface objects (security zones or interface groups) that contain the interfaces for the
device that protects the servers. In this example, we will assume the interface objects are security zones named
inside and dmz. To configure interface objects, select Objects > Object Management, then select Interface.

Firepower Management Center Configuration Guide, Version 6.3

1244
Network Address Translation (NAT)
Different Translation Depending on the Destination Address and Port (Dynamic Manual PAT)

Procedure

Step 1 Create a network object for the inside network.

a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
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.
a) Click Add Network > Add Object.
b) Name the network object (for example, TelnetWebServer) and enter the host address 209.165.201.11.

c) Click Save.
Step 3 Create a network object for the PAT address when using Telnet.
a) Click Add Network > Add Object.
b) Name the network object (for example, PATaddress1) and enter the host address 209.165.202.129.

c) Click Save.
Step 4 Create a network object for the PAT address when using HTTP.
a) Click Add Network > Add Object.
b) Name the network object (for example, PATaddress2) and enter the host address 209.165.202.130.

Firepower Management Center Configuration Guide, Version 6.3

1245
 Network Address Translation (NAT)
Different Translation Depending on the Destination Address and Port (Dynamic Manual PAT)

c) Click Save.
Step 5 Configure dynamic manual PAT for Telnet access.
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = dmz.

e) On the Translation tab, configure the following:

• Original Source = myInsideNetwork network object.
• Translated Source > Address= PATaddress1 network object.
• 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.

Firepower Management Center Configuration Guide, Version 6.3

1246
Network Address Translation (NAT)
Different Translation Depending on the Destination Address and Port (Dynamic Manual PAT)

f) Click Save.
Step 6 Configure dynamic manual PAT for web access.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.

c) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = dmz.

d) On the Translation tab, configure the following:

• Original Source = myInsideNetwork network object.
• Translated Source > Address= PATaddress2 network object.
• 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).

Firepower Management Center Configuration Guide, Version 6.3

1247
 Network Address Translation (NAT)
NAT and Site-to-Site VPN

e) Click Save.
Step 7 Click Save on the NAT rule page.

NAT and Site-to-Site VPN

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

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.

Firepower Management Center Configuration Guide, Version 6.3

1248
Network Address Translation (NAT)
NAT and Site-to-Site VPN

Figure 47: Interface PAT and Identity NAT for Site-to-Site VPN

The following example explains the configuration for Firewall1 (Boulder).

Before you begin

Ensure that you have interface objects (security zones or interface groups) that contain the interfaces for the
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.

a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Identify the Boulder inside network.
Name the network object (for example, boulder-network) and enter the network address, 10.1.1.0/24.

Firepower Management Center Configuration Guide, Version 6.3

1249
 Network Address Translation (NAT)
NAT and Site-to-Site VPN

d) Click Save.
e) Click Add Network > Add Object and define the inside San Jose network.
Name the network object (for example, sanjose-network) and enter the network address 10.2.2.0/24.

f) Click Save.
Step 2 Configure manual identity NAT for the Boulder network when going over the VPN to San Jose on Firewall1
(Boulder).
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Static.

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside-boulder.
• Destination Interface Objects = outside-boulder.

e) On the Translation tab, configure the following:

• 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 the Advanced tab, select Do not proxy ARP on Destination interface.

Firepower Management Center Configuration Guide, Version 6.3

1250
Network Address Translation (NAT)
NAT and Site-to-Site VPN

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.
b) Configure the following properties:
• NAT Rule = Manual NAT Rule.
• Type = Dynamic.
• Insert Rule = any position after the first rule. Because this rule will apply to any destination address,
the rule that uses sanjose-network as the destination must come before this rule, or the sanjose-network
rule will never be matched. The default is to place new manual NAT rules at the end of the "NAT
Rules Before Auto NAT" section.

c) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside-boulder.
• Destination Interface Objects = outside-boulder.

d) On the Translation tab, configure the following:

• Original Source = boulder-network object.
• Translated Source = Destination Interface IP. This option configures interface PAT using the
interface contained in the destination interface object.
• Original Destination > Address = any (leave blank).
• Translated Destination = any (leave blank).

Firepower Management Center Configuration Guide, Version 6.3

1251
 Network Address Translation (NAT)
Rewriting DNS Queries and Responses Using NAT

e) Click Save.
Step 4 If you are also managing Firewall2 (San Jose), you can configure similar rules for that device.
• The manual identity NAT rule would be for sanjose-network when the destination is boulder-network.
Create new interface objects for the Firewall2 inside and outside networks.
• The manual dynamic interface PAT rule would be for sanjose-network when the destination is "any."

Rewriting DNS Queries and Responses Using NAT

You might need to configure the Firepower Threat Defense device to modify DNS replies by replacing the
address in the reply with an address that matches the NAT configuration. You can configure DNS modification
when you configure each translation rule. DNS modification is also known as DNS doctoring.
This feature rewrites the address in DNS queries and replies that match a NAT rule (for example, the A record
for IPv4, the AAAA record for IPv6, or the PTR record for reverse DNS queries). For DNS replies traversing
from a mapped interface to any other interface, the record is rewritten from the mapped value to the real value.
Inversely, for DNS replies traversing from any interface to a mapped interface, the record is rewritten from
the real value to the mapped value.
Following are the main circumstances when you would need to configure DNS rewrite on a NAT rule.
• The rule is NAT64 or NAT46, and the DNS server is on the outside network. You need DNS rewrite to
convert between DNS A records (for IPv4) and AAAA records (for IPv6).
• The DNS server is on the outside, clients are on the inside, and some of the fully-qualified domain names
that the clients use resolve to other inside hosts.
• The DNS server is on the inside and responds with private IP addresses, clients are on the outside, and
the clients access fully-qualified domain names that point to servers that are hosted on the inside.

DNS Rewrite Limitations

Following are some limitations with DNS rewrite:
• DNS rewrite is not applicable for PAT because multiple PAT rules are applicable for each A or AAAA
record, and the PAT rule to use is ambiguous.

Firepower Management Center Configuration Guide, Version 6.3

1252
 Network Address Translation (NAT)
DNS64 Reply Modification

• If you configure a manual NAT rule, you cannot configure DNS modification if you specify the destination
address as well as the source address. These kinds of rules can potentially have a different translation
for a single address when going to A vs. B. Therefore, the Firepower Threat Defense device cannot
accurately match the IP address inside the DNS reply to the correct twice NAT rule; the DNS reply does
not contain information about which source/destination address combination was in the packet that
prompted the DNS request.
• You must enable DNS application inspection with DNS NAT rewrite enabled for NAT rules to rewrite
DNS queries and responses. By default, DNS inspection with DNS NAT rewrite enabled is globally
applied, so you probably do not need to change the inspection configuration.
• DNS rewrite is actually done on the xlate entry, not the NAT rule. Thus, if there is no xlate for a dynamic
rule, rewrite cannot be done correctly. The same problem does not occur for static NAT.
• DNS rewrite does not rewrite DNS Dynamic Update messages (opcode 5).

The following topics provide examples of DNS rewrite in NAT rules.

DNS64 Reply Modification

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

The following figure shows an FTP server and DNS server on the outside IPv4 network. The system has a
static translation for the outside server. In this case, when an inside IPv6 user requests the address for
ftp.cisco.com from the DNS server, the DNS server responds with the real address, 209.165.200.225.
Because you want inside users to use the mapped address for ftp.cisco.com (2001:DB8::D1A5:C8E1, where
D1A5:C8E1 is the IPv6 equivalent of 209.165.200.225) you need to configure DNS reply modification for
the static translation. This example also includes a static NAT translation for the DNS server, and a PAT rule
for the inside IPv6 hosts.

Firepower Management Center Configuration Guide, Version 6.3

1253
 Network Address Translation (NAT)
DNS64 Reply Modification

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 for the FTP server, DNS server, inside network, and PAT pool.
a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the real FTP server address.
Name the network object (for example, ftp_server) and enter the host address, 209.165.200.225.

Firepower Management Center Configuration Guide, Version 6.3

1254
Network Address Translation (NAT)
DNS64 Reply Modification

d) Click Save.
e) Click Add Network > Add Object and define the FTP server's translated IPv6 address.
Name the network object (for example, ftp_server_v6) and enter the host address,
2001:DB8::D1A5:C8E1.

f) Click Save.
g) Click Add Network > Add Object and define the DNS server's real address.
Name the network object (for example, dns_server) and enter the host address, 209.165.201.15.

h) Click Save.
i) Click Add Network > Add Object and define the DNS server's translated IPv6 address.
Name the network object (for example, dns_server_v6) and enter the host address,
2001:DB8::D1A5:C90F (where D1A5:C90F is the IPv6 equivalent of 209.165.201.15).

Firepower Management Center Configuration Guide, Version 6.3

1255
 Network Address Translation (NAT)
DNS64 Reply Modification

j) Click Save.
k) Click Add Network > Add Object and define the inside IPv6 network.
Name the network object (for example, inside_v6) and enter the network address, 2001:DB8::/96.

l) Click Save.
m) Click Add Network > Add Object and define the IPv4 PAT pool for the inside IPv6 network.
Name the network object (for example, ipv4_pool) and enter the range 209.165.200.230-209.165.200.235.

n) Click Save.
Step 2 Configure the static NAT rule with DNS modification for the FTP server.
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.

Firepower Management Center Configuration Guide, Version 6.3

1256
Network Address Translation (NAT)
DNS64 Reply Modification

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = outside.
• Destination Interface Objects = inside.

e) On the Translation tab, configure the following:

• Original Source = ftp_server network object.
• Translated Source > Address = ftp_server_v6 network object.

f) On the Advanced tab, select the following options:

• Translate DNS replies that match this rule.
• Net to Net Mapping, because this is a one-to-one NAT46 translation.

g) Click OK.
Step 3 Configure the static NAT rule for the DNS server.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.

c) On the Interface Objects tab, configure the following:

• Source Interface Objects = outside.
• Destination Interface Objects = inside.

d) On the Translation tab, configure the following:

• Original Source = dns_server network object.
• Translated Source > Address = dns_server_v6 network object.

e) On the Advanced tab, select Net to Net Mapping, because this is a one-to-one NAT46 translation.

Firepower Management Center Configuration Guide, Version 6.3

1257
 Network Address Translation (NAT)
DNS64 Reply Modification

f) Click OK.
Step 4 Configure the dynamic NAT with a PAT pool rule for the inside IPv6 network.
a) Click Add Rule.
b) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Dynamic.

c) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = outside.

d) On the Translation tab, configure the following:

• Original Source = inside_v6 network object.
• Translated Source > Address = leave this field empty.

e) On the PAT Pool tab, configure the following:

• Enable PAT Pool = select this option.
• Translated Source > Address = ipv4_pool network object.

Firepower Management Center Configuration Guide, Version 6.3

1258
 Network Address Translation (NAT)
DNS Reply Modification, DNS Server on Outside

f) Click OK.

DNS Reply Modification, DNS Server on Outside

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

The following figure shows a DNS server that is accessible from the outside interface. A server, ftp.cisco.com,
is on the inside interface. You configure NAT to statically translate the ftp.cisco.com real address (10.1.3.14)
to a mapped address (209.165.201.10) that is visible on the outside network.
In this case, you want to enable DNS reply modification on this static rule so that inside users who have access
to ftp.cisco.com using the real address receive the real address from the DNS server, and not the mapped
address.
When an inside host sends a DNS request for the address of ftp.cisco.com, the DNS server replies with the
mapped address (209.165.201.10). The system refers to the static rule for the inside server and translates the
address inside the DNS reply to 10.1.3.14. If you do not enable DNS reply modification, then the inside host
attempts to send traffic to 209.165.201.10 instead of accessing ftp.cisco.com directly.

Firepower Management Center Configuration Guide, Version 6.3

1259
 Network Address Translation (NAT)
DNS Reply Modification, DNS Server on Outside

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 for the FTP server.

a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the real FTP server address.
Name the network object (for example, ftp_server) and enter the host address, 10.1.3.14.

Firepower Management Center Configuration Guide, Version 6.3

1260
Network Address Translation (NAT)
DNS Reply Modification, DNS Server on Outside

d) Click Save.
e) Click Add Network > Add Object and define the FTP server's translated address.
Name the network object (for example, ftp_server_outside) and enter the host address, 209.165.201.10.

f) Click Save.
Step 2 Configure the static NAT rule with DNS modification for the FTP server.
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = inside.
• Destination Interface Objects = outside.

e) On the Translation tab, configure the following:

• Original Source = ftp_server network object.
• Translated Source > Address = ftp_server_outside network object.

f) On the Advanced tab, select Translate DNS replies that match this rule.

Firepower Management Center Configuration Guide, Version 6.3

1261
 Network Address Translation (NAT)
DNS Reply Modification, DNS Server on Host Network

g) Click OK.

DNS Reply Modification, DNS Server on Host Network

Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Access Admin
Administrator
Network Admin

The following figure shows an FTP server and DNS server on the outside. The system has a static translation
for the outside server. In this case, when an inside user requests the address for ftp.cisco.com from the DNS
server, the DNS server responds with the real address, 209.165.20.10. Because you want inside users to use
the mapped address for ftp.cisco.com (10.1.2.56) you need to configure DNS reply modification for the static
translation.

Firepower Management Center Configuration Guide, Version 6.3

1262
Network Address Translation (NAT)
DNS Reply Modification, DNS Server on Host Network

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 for the FTP server.

a) Choose Objects > Object Management.
b) Select Network from the table of contents and click Add Network > Add Object.
c) Define the real FTP server address.
Name the network object (for example, ftp_server) and enter the host address, 209.165.201.10.

Firepower Management Center Configuration Guide, Version 6.3

1263
 Network Address Translation (NAT)
DNS Reply Modification, DNS Server on Host Network

d) Click Save.
e) Click Add Network > Add Object and define the FTP server's translated address.
Name the network object (for example, ftp_server_translated) and enter the host address, 10.1.2.56.

f) Click Save.
Step 2 Configure the static NAT rule with DNS modification for the FTP server.
a) Select Devices > NAT and create or edit a FTD NAT policy.
b) Click Add Rule.
c) Configure the following properties:
• NAT Rule = Auto NAT Rule.
• Type = Static.

d) On the Interface Objects tab, configure the following:

• Source Interface Objects = outside.
• Destination Interface Objects = inside.

e) On the Translation tab, configure the following:

• Original Source = ftp_server network object.
• Translated Source > Address = ftp_server_translated network object.

f) On the Advanced tab, select Translate DNS replies that match this rule.

Firepower Management Center Configuration Guide, Version 6.3

1264
 Network Address Translation (NAT)
History for FTD NAT

g) Click OK.

History for FTD NAT

Feature Version Details

Network Address Translation (NAT) 6.0.1 The NAT policy for Firepower Threat Defense was added.
for Firepower Threat Defense.
New/modified screens: Threat Defense was added as a type of NAT policy
to the Devices > NAT page.
Supported platforms: Firepower Threat Defense

Support for network range objects in 6.1.0 You can now use network range objects in Firepower Threat Defense NAT
NAT for Firepower Threat Defense. rules where appropriate.

Firepower Management Center Configuration Guide, Version 6.3

1265
 Network Address Translation (NAT)
History for FTD NAT

Firepower Management Center Configuration Guide, Version 6.3

1266
PA R T XVI
7000 and 8000 Series Advanced Deployment
Options
• Setting Up Virtual Switches, on page 1269
• Setting Up Virtual Routers, on page 1279
• Aggregate Interfaces and LACP, on page 1311
• Hybrid Interfaces, on page 1325
• Gateway VPNs, on page 1329
 CHAPTER 57
Setting Up Virtual Switches
The following topics describe how to set up virtual switches in the Firepower System:
• Virtual Switches, on page 1269
• Switched Interface Configuration, on page 1269
• Virtual Switch Configuration, on page 1274

Virtual Switches
You can configure a 7000 or 8000 Series device in a Layer 2 deployment so that it provides packet switching
between two or more networks. In a Layer 2 deployment, you can configure virtual switches to operate as
standalone broadcast domains, dividing your network into logical segments. A virtual switch uses the media
access control (MAC) address from a host to determine where to send packets.
When you configure a virtual switch, the switch initially broadcasts packets through every available port on
the switch. Over time, the switch uses tagged return traffic to learn which hosts reside on the networks
connected to each port.
A virtual switch must contain two or more switched interfaces to handle traffic. For each virtual switch, traffic
becomes limited to the set of ports configured as switched interfaces. For example, if you configure a virtual
switch with four switched interfaces, packets sent in through one port for broadcast can only be sent out of
the remaining three ports on the switch.
When you configure a physical switched interface, you must assign it to a virtual switch. You can also define
additional logical switched interfaces on a physical port as needed. You can group multiple physical interfaces
into a single logical switched interface called a link aggregation group (LAG). This single aggregate logical
link provides higher bandwidth, redundancy, and load-balancing between two endpoints.

Caution If a Layer 2 deployment fails for any reason, the device no longer passes traffic.

Switched Interface Configuration

You can set up switched interfaces to have either physical or logical configurations. You can configure physical
switched interfaces for handling untagged VLAN traffic. You can also create logical switched interfaces for
handling traffic with designated VLAN tags.

Firepower Management Center Configuration Guide, Version 6.3

1269
 7000 and 8000 Series Advanced Deployment Options
Switched Interface Configuration Notes

In a Layer 2 deployment, the system drops any traffic received on an external physical interface that does not
have a switched interface waiting for it. If the system receives a packet with no VLAN tag and you have not
configured a physical switched interface for that port, it drops the packet. If the system receives a VLAN-tagged
packet and you have not configured a logical switched interface, it also drops the packet.
The system handles traffic that has been received with VLAN tags on switched interfaces by stripping the
outermost VLAN tag on ingress before any rules evaluation or forwarding decisions. Packets leaving the
device through a VLAN-tagged logical switched interface are encapsulated with the associated VLAN tag on
egress.
Note that if you change the parent physical interface to inline or passive, the system deletes all the associated
logical interfaces.

Switched Interface Configuration Notes

You can configure one or more physical ports on a managed device as switched interfaces. You must assign
a physical switched interface to a virtual switch before it can handle traffic. You can configure link mode
settings and MDI/MDIX settings only for copper interfaces.

Note Interfaces on 8000 Series appliances do not support half-duplex options.

For each physical switched interface, you can add multiple logical switched interfaces. You must associate
each logical interface with a VLAN tag to handle traffic received by the physical interface with that specific
tag. You must assign a logical switched interface to a virtual switch to handle traffic.
When configuring a switched interface, the range within which you can set the MTU can vary depending on
the Firepower System device model and interface type.
The range of MTU values can vary depending on the model of the managed device and the interface type.

Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 312 for more information.

To edit an existing logical switched interface, click the edit icon ( ) next to the interface.
When you delete a logical switched interface, you remove it from the physical interface where it resides, as
well as the virtual switch and security zone it is associated with.
Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Firepower Management Center Configuration Guide, Version 6.3

1270
 7000 and 8000 Series Advanced Deployment Options
Configuring Physical Switched Interfaces

Configuring Physical Switched Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to configure the switched interface, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Next to the interface you want to configure as a switched interface, click the edit icon ( ).
Step 4 Click the Switched tab.
Step 5 If you want to associate the switched 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 380.

Step 6 If you want to associate the switched interface with a virtual switch, do one of the following:
• Choose an existing virtual switch from the Virtual Switch drop-down list.
• Choose New to add a new virtual switch; see Adding Virtual Switches, on page 1275.

Step 7 Check the Enabled check box to allow the switched interface to handle traffic.
Note If you clear the check box, the interface becomes disabled so that users cannot access it for security
purposes.

Step 8 From the Mode drop-down list, choose an option to designate the link mode, or choose Autonegotiation to
specify that the interface is configured to auto negotiate speed and duplex settings.
Mode settings are available only for copper interfaces.
Interfaces on 8000 Series appliances do not support half-duplex options.

Step 9 From the MDI/MDIX drop-down list, choose an option to designate whether the interface is configured for
MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and
MDIX to attain link.

Step 10 In the MTU field, enter a maximum transmission unit (MTU), which designates the largest size packet allowed.
The range of MTU values can vary depending on the model of the managed device and the interface type.

Firepower Management Center Configuration Guide, Version 6.3

1271
 7000 and 8000 Series Advanced Deployment Options
Adding Logical Switched Interfaces

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 312 for
more information.

Step 11 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Adding Logical Switched Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to add the switched interface, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Choose Add Logical Interface from the Add drop-down menu.
Step 4 Click Switched.
Step 5 From the Interface drop-down list, choose the physical interface that will receive the VLAN-tagged traffic.
Step 6 In the VLAN Tag field, enter a tag value that gets assigned to inbound and outbound traffic on this interface.
The tag value can be any integer from 1 to 4094.

Step 7 If you want to associate the switched 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 380.

Step 8 If you want to associate the switched interface with a virtual switch, do one of the following:
• Choose an existing virtual switch from the Virtual Switch drop-down list.
• Choose New to add a new virtual switch; see Adding Virtual Switches, on page 1275.

Firepower Management Center Configuration Guide, Version 6.3

1272
 7000 and 8000 Series Advanced Deployment Options
Deleting Logical Switched Interfaces

Step 9 Check the Enabled check box to allow the switched interface to handle traffic.
If you clear the check box, the interface becomes disabled and administratively taken down. If you disable a
physical interface, you also disable all of the logical interfaces associated with it.

Step 10 In the MTU field, enter a maximum transmission unit (MTU), which designates the largest size packet allowed.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 312 for
more information.

Step 11 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Deleting Logical Switched Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the managed device that contains the switched interface you want to delete, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Next to the logical switched interface you want to delete, click the delete icon ( ).
Step 4 When prompted, confirm that you want to delete the interface.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1273
 7000 and 8000 Series Advanced Deployment Options
Virtual Switch Configuration

Virtual Switch Configuration

Before you can use switched interfaces in a Layer 2 deployment, you must configure virtual switches and
assign switched interfaces to them. A virtual switch is a group of switched interfaces that process inbound
and outbound traffic through your network.

Virtual Switch Configuration Notes

You can add virtual switches from the Virtual Switches tab of the Device Management page. The Virtual
Switches tab displays a list of all the virtual switches you have configured on a device. The page includes
summary information about each switch.

Table 88: Virtual Switches Table View Fields

Field Description

Name The name of the virtual switch.

Interfaces All switched interfaces that are assigned to the virtual

switch. Interfaces that you have disabled from the
Interfaces tab are not available.

Hybrid Interface The optionally configured hybrid interface that ties

the virtual switch to a virtual router.

Unicast Packets Unicast packet statistics for the virtual switch,

including:
• Unicast packets received
• Unicast packets forwarded (excludes drops by
host)
• Unicast packets unintentionally dropped

Broadcast Packets Broadcast packet statistics for the virtual switch,

including:
• Broadcast packets received
• Broadcast packets forwarded
• Broadcast packets unintentionally dropped

You can also add switches as you configure switched interfaces. You can assign only switched interfaces to
a virtual switch. If you want to create a virtual switch before you configure the switched interfaces on your
managed devices, you can create an empty virtual switch and add interfaces to it later.

Tip
To edit an existing virtual switch, click the edit icon ( ) next to the switch.

Firepower Management Center Configuration Guide, Version 6.3

1274
 7000 and 8000 Series Advanced Deployment Options
Adding Virtual Switches

Adding Virtual Switches

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to add the virtual switch, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Switches tab.

Step 4 Click Add Virtual Switch.
Step 5 Enter a name in the Name field.
Step 6 From the Available list, choose one or more switched interfaces to add to the virtual switch.
Tip Interfaces that you have disabled from the Interfaces tab are not available; disabling an interface
after you add it removes it from the configuration.

Step 7 Click Add.

Step 8 If you want to tie the virtual switch to a virtual router, choose a hybrid interface from the Hybrid Interface
drop-down list.
Step 9 Optionally, configure advanced settings for the switch; see Advanced Virtual Switch Settings, on page 1275
Step 10 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Logical Hybrid Interfaces, on page 1325

Advanced Virtual Switch Settings

Adding Static MAC Entries
Over time, a virtual switch learns MAC addresses by tagging return traffic from the network. You can manually
add a static MAC entry, which designates that a MAC address resides on a specific port. Regardless of whether
you ever receive traffic from that port, the MAC address remains static in the table. You can specify one or
more static MAC addresses for each virtual switch.

Firepower Management Center Configuration Guide, Version 6.3

1275
 7000 and 8000 Series Advanced Deployment Options
Configuring Advanced Virtual Switch Settings

Enabling Spanning Tree Protocol (STP) and Dropping Bridge Protocol Data Units (BPDU)
STP is a network protocol used to prevent network loops. BPDUs are exchanged through the network, carrying
information about network bridges. The protocol uses BPDUs to identify and select the fastest network links,
if there are redundant links in the network. If a network link fails, Spanning Tree fails over to an existing
alternate link.

Note Cisco strongly recommends that you enable STP when configuring a virtual switch that you plan to deploy
in a 7000 or 8000 Series device high-availability pair. Only enable STP if your virtual switch switches traffic
between multiple network interfaces.

If your virtual switch routes traffic between VLANs, similar to a router on a stick, BPDUs enter and exit the
device through different logical switched interfaces, but the same physical switched interface. As a result,
STP identifies the device as a redundant network loop, which can cause issues in certain Layer 2 deployments.
To prevent this, you can configure the virtual switch at the domain level to have the device drop BPDUs when
monitoring traffic. You can only drop BPDUs if you disable STP.

Note Drop BPDUs only if your virtual swtich routes traffic between VLANs on a single physical interface.

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

Note that if you associate the virtual switch with a logical hybrid interface, the switch uses the same strict
TCP enforcement setting as the virtual router associated with the logical hybrid interface. You cannot specify
strict TCP enforcement on the switch in this case.

Configuring Advanced Virtual Switch Settings

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Firepower Management Center Configuration Guide, Version 6.3

1276
 7000 and 8000 Series Advanced Deployment Options
Deleting Virtual Switches

Step 2 Next to the device that contains the virtual switch you want to edit, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Switches tab.

Step 4 Next to the virtual switch that you want to edit, click the edit icon ( ).
Step 5 Click the Advanced tab.
Step 6 To add a static MAC entry, click Add.
Step 7 In the MAC Address field, enter the address using the standard format of six groups of two hexadecimal
digits separated by colons (for example, 01:23:45:67:89:AB).
Note Broadcast addresses (00:00:00:00:00:00 and FF:FF:FF:FF:FF:FF) cannot be added as static MAC
addresses.

Step 8 From the Interface drop-down list, choose the interface where you want to assign the MAC address.
Step 9 Click OK.
Step 10 If you want to enable the Spanning Tree Protocol, check the Enable Spanning Tree Protocol check box.
Step 11 If you want to enable strict TCP enforcement, check the Strict TCP Enforcement check box.
If you associate the virtual switch with a logical hybrid interface, this option does not appear and the switch
uses the same setting as the virtual router associated with the logical hybrid interface.

Step 12 If you want to drop BPDUs at the domain level, check the Drop BPDUs check box.
Step 13 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Deleting Virtual Switches

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

When you delete a virtual switch, any switched interfaces assigned to the switch become available for inclusion
in another switch.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the managed device that contains the virtual switch you want to delete, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Firepower Management Center Configuration Guide, Version 6.3

1277
 7000 and 8000 Series Advanced Deployment Options
Deleting Virtual Switches

Step 3 Click the Virtual Switches tab.

Step 4 Next to the virtual switch that you want to delete, click the delete icon ( ).
Step 5 When prompted, confirm that you want to delete the virtual switch.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1278
 CHAPTER 58
Setting Up Virtual Routers
The following topics describe how to set up virtual routers in the Firepower System:
• Virtual Routers, on page 1279
• Routed Interfaces, on page 1280
• Configuring Physical Routed Interfaces, on page 1281
• Adding Logical Routed Interfaces, on page 1283
• Deleting Logical Routed Interfaces, on page 1285
• Configuring SFRP, on page 1286
• Virtual Router Configuration, on page 1287
• Adding Virtual Routers, on page 1288
• DHCP Relay, on page 1289
• Static Routes, on page 1291
• Dynamic Routing, on page 1293
• Virtual Router Filters, on page 1305
• Adding Virtual Router Authentication Profiles, on page 1308
• Viewing Virtual Router Statistics, on page 1309
• Deleting Virtual Routers, on page 1309

Virtual Routers
You can configure a managed device in a Layer 3 deployment so that it routes traffic between two or more
interfaces. To route traffic, you must assign an IP address to each interface and assign the interfaces to the
virtual router. The interfaces assigned to virtual routers can be physical, logical, or link aggregation group
(LAG) interfaces.
You can configure the system to route packets by making packet forwarding decisions according to the
destination address. Interfaces configured as routed interfaces receive and forward the Layer 3 traffic. Routers
obtain the destination from the outgoing interface based on the forwarding criteria, and access control rules
designate the security policies to be applied.
In Layer 3 deployments, you can define static routes. In addition, you can configure Routing Information
Protocol (RIP) and Open Shortest Path First (OSPF) dynamic routing protocols. You can also configure a
combination of static routes and RIP or static routes and OSPF.
Note that you can only configure virtual routers, physical routed interfaces, or logical routed interfaces on a
7000 or 8000 Series device.

Firepower Management Center Configuration Guide, Version 6.3

1279
 7000 and 8000 Series Advanced Deployment Options
Routed Interfaces

Caution If a Layer 3 deployment fails for any reason, the device no longer passes traffic.

Related Topics
LAG Configuration, on page 1312

Routed Interfaces
You can set up routed interfaces with either physical or logical configurations. You can configure physical
routed interfaces for handling untagged VLAN traffic. You can also create logical routed interfaces for handling
traffic with designated VLAN tags.
In a Layer 3 deployment, the system drops any traffic received on an external physical interface that does not
have a routed interface waiting for it. The system drops a packet if:
• It receives a packet with no VLAN tag, and you have not configured a physical routed interface for that
port.
• It receives a VLAN-tagged packet, and you have not configured a logical routed interface for that port.

The system handles traffic that has been received with VLAN tags on switched interfaces by stripping the
outermost VLAN tag on ingress prior to any rules evaluation or forwarding decisions. Packets leaving the
device through a VLAN-tagged logical routed interface are encapsulated with the associated VLAN tag on
egress. The system drops any traffic received with a VLAN tag after the stripping process completes.
You can add static Address Resolution Protocol (ARP) entries to a routed interface. If an external host needs
to know the MAC address of the destination IP address it needs to send traffic to on your local network, it
sends an ARP request. When you configure static ARP entries, the virtual router responds with an IP address
and associated MAC address.
Note that disabling the ICMP Enable Responses option for logical routed interfaces does not prevent ICMP
responses in all scenarios. You can add network-based rules to an access control policy to drop packets where
the destination IP is the routed interface’s IP and the protocol is ICMP.
If you have enabled the Inspect Local Router Traffic option on the managed device, the system drops the
packets before they reach the host, thereby preventing any response.
The range of MTU values can vary depending on the model of the managed device and the interface type.

Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 312 for more information.

If you change the parent physical interface to inline or passive, the system deletes all the associated logical
interfaces.
Related Topics
Advanced Device Settings, on page 504
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532

Firepower Management Center Configuration Guide, Version 6.3

1280
 7000 and 8000 Series Advanced Deployment Options
Configuring Physical Routed Interfaces

Snort® Restart Scenarios, on page 311

Configuring Physical Routed Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can configure one or more physical ports on a managed device as routed interfaces. You must assign a
physical routed interface to a virtual router before it can route traffic.

Caution Adding a routed interface pair on a 7000 or 8000 Series device 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 312 for more information.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Next to the interface you want to modify, click the edit icon ( ).
Step 4 Click Routed to display the routed interface options.
Step 5 If you want to apply 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 380.

Step 6 If you want to specify a virtual router, do one of the following:

• Choose an existing virtual router from the Virtual Router drop-down list.
• Choose New to add a new virtual router; Adding Virtual Routers, on page 1288.

Step 7 Check the Enabled check box to allow the routed interface to handle traffic. If you clear the check box, the
interface becomes disabled so that users cannot access it for security purposes.
Step 8 From the Mode drop-down list, choose an option to designate the link mode, or choose Autonegotiation to
specify that the interface is configured to auto negotiate speed and duplex settings.
Mode settings are available only for copper interfaces.
Interfaces on 8000 Series appliances do not support half-duplex options.

Step 9 From the MDI/MDIX drop-down list, choose an option to designate whether the interface is configured for
MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.

Firepower Management Center Configuration Guide, Version 6.3

1281
 7000 and 8000 Series Advanced Deployment Options
Configuring Physical Routed Interfaces

Normally, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and MDIX
to attain link.
MDI/MDIX settings are available only for copper interfaces.

Step 10 In the MTU field, choose a maximum transmission unit (MTU), which designates the largest size packet
allowed.
The MTU is the Layer 2 MTU/MRU and not the Layer 3 MTU.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 312 for
more information.

Step 11 Next to ICMP, check the Enable Responses check box to allow the interface to respond to ICMP traffic such
as pings and traceroute.
Step 12 Next to IPv6 NDP, check the Enable Router Advertisement check box to enable the interface to broadcast
router advertisements.
Step 13 To add an IP address, click Add.
Step 14 In the Address field, enter the routed interface’s IP address and subnet mask using CIDR notation.
Note the following:
• You cannot add network and broadcast addresses, or the static MAC addresses 00:00:00:00:00:00 and
FF:FF:FF:FF:FF:FF.
• You cannot add identical IP addresses, regardless of subnet mask, to interfaces in virtual routers.

Step 15 If your organization uses IPv6 addresses and you want to set the IP address of the interface automatically,
check the Address Autoconfiguration check box next to the IPv6 field.
Step 16 For Type, choose either Normal or SFRP.
For SFRP options, see Configuring SFRP, on page 1286 for more information.

Step 17 Click OK.

• To edit an IP address, click the edit icon ( ).

• To delete an IP address, click the delete icon ( ).

Note When adding an IP address to a routed interface of a 7000 or 8000 Series device in a
high-availability pair, you must add a corresponding IP address to the routed interface on the
high-availability pair peer.

Step 18 To add a static ARP entry, click Add.

Step 19 In the IP Address field, enter an IP address for the static ARP entry.
Step 20 In the MAC Address field, enter a MAC address to associate with the IP address. Use the standard address
format of six groups of two hexadecimal digits separated by colons (for example, 01:23:45:67:89:AB).

Firepower Management Center Configuration Guide, Version 6.3

1282
 7000 and 8000 Series Advanced Deployment Options
Adding Logical Routed Interfaces

Step 21 Click OK.

Tip
To edit a static ARP entry, click the edit icon ( ). To delete a static ARP entry, click the delete
icon ( ).

Step 22 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Adding Logical Routed Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

For each physical routed interface, you can add multiple logical routed interfaces. You must associate each
logical interface with a VLAN tag to handle traffic received by the physical interface with that specific tag.
You must assign a logical routed interface to a virtual router to route traffic.

Caution Adding a routed interface pair on 7000 or 8000 Series devices 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 312 for more information.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click Add Interface.

Step 4 Click Routed to display the routed interface options.
Step 5 From the Interface drop-down list, choose the physical interface where you want to add the logical interface.
Step 6 In the VLAN Tag field, enter a tag value that gets assigned to inbound and outbound traffic on this interface.
The value can be any integer from 1 to 4094.

Firepower Management Center Configuration Guide, Version 6.3

1283
 7000 and 8000 Series Advanced Deployment Options
Adding Logical Routed Interfaces

Step 7 If you want to apply 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 380.

Step 8 If you want to specify a virtual router, do one of the following:

• Choose an existing virtual router from the Virtual Router drop-down list.
• Choose New to add a new virtual router; Adding Virtual Routers, on page 1288.

Step 9 Check the Enabled check box to allow the routed interface to handle traffic.
If you clear the check box, the interface becomes disabled and administratively taken down. If you disable a
physical interface, you also disable all of the logical interfaces associated with it.

Step 10 In the MTU field, enter a maximum transmission unit (MTU), which designates the largest size packet allowed.
The MTU is the Layer 2 MTU/MRU and not the Layer 3 MTU.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 312 for
more information.

Step 11 Next to ICMP, check the Enable Responses check box to communicate updates or error information to other
routers, intermediary devices, or hosts.
Step 12 Next to IPv6 NDP, check the Enable Router Advertisement check box to enable the interface to broadcast
router advertisements.
Step 13 To add an IP address, click Add.
Step 14 In the Address field, enter the IP address in CIDR notation.
Note the following:
• You cannot add network and broadcast addresses, or the static MAC addresses 00:00:00:00:00:00 and
FF:FF:FF:FF:FF:FF.
• You cannot add identical IP addresses, regardless of subnet mask, to interfaces in virtual routers.

Step 15 If your organization uses IPv6 addresses and you want to set the IP address of the interface automatically,
choose the Address Autoconfiguration check box next to the IPv6 field.
Step 16 For Type, choose either Normal or SFRP.
For SFRP options, see Configuring SFRP, on page 1286 for more information.

Step 17 Click OK.

• To edit an IP address, click the edit icon ( ).

• To delete an IP address, click the delete icon ( ).

Firepower Management Center Configuration Guide, Version 6.3

1284
 7000 and 8000 Series Advanced Deployment Options
Deleting Logical Routed Interfaces

Note When you add an IP address to a routed interface of a 7000 or 8000 Series device in a
high-availability pair, you must add a corresponding IP address to the routed interface on the
high-availability pair peer.

Step 18 To add a static ARP entry, click Add.

Step 19 In the IP Address field, enter an IP address for the static ARP entry.
Step 20 In the MAC Address field, enter a MAC address to associate with the IP address. Use the standard address
format of six groups of two hexadecimal digits separated by colons (for example, 01:23:45:67:89:AB).
Step 21 Click OK. The static ARP entry is added.
Tip
To edit a static ARP entry, click the edit icon ( ). To delete a static ARP entry, click the delete
icon ( ).

Step 22 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Deleting Logical Routed Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

When you delete a logical routed interface, you remove it from the physical interface where it resides, as well
as its assigned virtual router and security zone.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Next to the logical routed interface you want to delete, click the delete icon ( ).
Step 4 When prompted, confirm that you want to delete the interface.

Firepower Management Center Configuration Guide, Version 6.3

1285
 7000 and 8000 Series Advanced Deployment Options
Configuring SFRP

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring SFRP
Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can configure Cisco Redundancy Protocol (SFRP) to achieve network redundancy for high availability
on either a 7000 or 8000 Series device high-availability pair or individual devices. SFRP provides gateway
redundancy for both IPv4 and IPv6 addresses. You can configure SFRP on routed and hybrid interfaces.
If the interfaces are configured on individual devices, they must be in the same broadcast domain. You must
designate at least one of the interfaces as master and an equal number as backup. The system supports only
one master and one backup per IP address. If network connectivity is lost, the system automatically promotes
the backup to master to maintain connectivity.
The options you set for SFRP must be the same on all interfaces in a group of SFRP interfaces. Multiple IP
addresses in a group must be in the same master/backup state. Therefore, when you add or edit an IP address,
the state you set for that address propagates to all the addresses in the group. For security purposes, you must
enter values for Group ID and Shared Secret that are shared among the interfaces in the group.
To enable SFRP IP addresses on a virtual router, you must also configure one non-SFRP IP address. Note
that only one non-SFRP address should be configured per interface.
As all SFRPs in a group failover together, all SFRPs on the same virtual router should be in the same SFRP
group. In addition, you should also set up an HA link interface on each device in a high-availability pair when
using NAT, HA state sharing, or VPN. For more information on HA link interfaces, see Configuring HA Link
Interfaces, on page 529
For 7000 or 8000 Series devices in a high-availability pair, you designate the shared secret and the system
copies it to the high-availability pair peer along with the SFRP IP configuration. The shared secret authenticates
peer data.

Note Cisco does not recommend enabling more than one non-SFRP IP address on a 7000 or 8000 Series device
high-availability pair's routed or hybrid interface where one SFRP IP address is already configured. The system
does not perform NAT if a 7000 or 8000 Series device high-availability pair fails over while in standby mode.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Firepower Management Center Configuration Guide, Version 6.3

1286
 7000 and 8000 Series Advanced Deployment Options
Virtual Router Configuration

Step 3 Next to the interface where you want to configure SFRP, click the edit icon ( ).
Step 4 Choose the type of interface where you want to configure SFRP, either Routed or Hybrid.
Step 5 You can configure SFRP while adding or editing an IP address. Click Add to add an IP address. To edit an
IP address, click the edit icon ( ).
Step 6 For Type, choose SFRP to display the SFRP options.
Step 7 In the Group ID field, enter a value that designates a group of master or backup interfaces configured for
SFRP.
Step 8 For Priority, choose either Master or Backup to designate the preferred interface:
• For individual devices, you must set one interface to master on one device and the other to backup on a
second device.
• For 7000 or 8000 Seriesdevice high-availability pairs, when you set one interface as master, the other
automatically becomes the backup.

Step 9 In the Shared Secret field, enter a shared secret.

The Shared Secret field populates automatically for a group in a 7000 or 8000 Series device high-availability
pair.

Step 10 In the Adv. Interval (seconds) field, enter an interval for route advertisements for Layer 3 traffic.
Step 11 Click OK.
Step 12 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
About 7000 and 8000 Series Device High Availability, on page 549

Virtual Router Configuration

Caution Adding a virtual router on a 7000 or 8000 Series device 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 312 for more information.

Before you can use routed interfaces in a Layer 3 deployment, you must configure virtual routers and assign
routed interfaces to them. A virtual router is a group of routed interfaces that route Layer 3 traffic.
You can assign only routed and hybrid interfaces to a virtual router.
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

Firepower Management Center Configuration Guide, Version 6.3

1287
 7000 and 8000 Series Advanced Deployment Options
Adding Virtual Routers

• non-SYN/RST packets from the initiator on a TCP connection before the responder sends the SYN-ACK
• 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

Note that if you change the configuration of a Layer 3 interface to a non-Layer 3 interface or remove a Layer
3 interface from the virtual router, the router may fall into an invalid state. For example, if it is used in DHCPv6,
it may cause an upstream and downstream mismatch.

Adding Virtual Routers

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can add virtual routers from the Virtual Routers tab of the device management page. You can also add
routers as you configure routed interfaces.
If you want to create a virtual router before you configure the interfaces on your managed devices, you can
create an empty virtual router and add interfaces to it later.

Caution Adding a virtual router on a 7000 or 8000 Series device 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 312 for more information.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Tip If your devices are in a stack in a high-availability pair, choose the stack you want to modify from
the Selected Device drop-down list.

Step 4 Click Add Virtual Router.

Step 5 In the Name field, enter a name for the virtual router. You can use alphanumeric characters and spaces.
Step 6 Configure IPv6 static routing, OSPFv3, and RIPng on your virtual router by checking or clearing the IPv6
Support check box.
Step 7 If you do not want to enable strict TCP enforcement, clear the Strict TCP Enforcement check box. This
option is enabled by default.

Firepower Management Center Configuration Guide, Version 6.3

1288
 7000 and 8000 Series Advanced Deployment Options
DHCP Relay

Step 8 Choose one or more interfaces from the Available list under Interfaces, and click Add.
The Available list contains all enabled Layer 3 interfaces, routed and hybrid, on the device that you can assign
to the virtual router.
Tip
To remove a routed or hybrid interface from the virtual router, click the delete icon ( ). Disabling
a configured interface from the Interfaces tab also removes it.

Step 9 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

DHCP Relay
DHCP provides configuration parameters to Internet hosts. A DHCP client that has not yet acquired an IP
address cannot communicate directly with a DHCP server outside its broadcast domain. To allow DHCP
clients to communicate with DHCP servers, you can configure DHCP relay instances to handle cases where
the client is not on the same broadcast domain as the server.
You can set up DHCP relay for each virtual router you configure. By default, this feature is disabled. You
can enable either DHCPv4 relay or DHCPv6 relay.

Note You cannot run a DHCPv6 Relay chain through two or more virtual routers running on the same device.

Setting Up DHCPv4 Relay

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

The following procedure explains how to set up DHCPv4 relay on a virtual router.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router you want to modify, click the edit icon ( ).

Firepower Management Center Configuration Guide, Version 6.3

1289
 7000 and 8000 Series Advanced Deployment Options
Setting Up DHCPv6 Relay

Step 5 Check the DHCPv4 check box.

Step 6 Under the Servers field, enter a server IP address.
Step 7 Click Add.
You can add up to four DHCP servers.

Step 8 In the Max Hops field, enter the maximum number of hops from 1 to 255.
Step 9 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Setting Up DHCPv6 Relay

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You cannot run a DHCPv6 Relay chain through two or more virtual routers running on the same device.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router where you want to set up DHCP relay, click the edit icon ( ).
Step 5 Check the DHCPv6 check box.
Step 6 In the Interfaces field, check the check boxes next to one or more interfaces that have been assigned to the
virtual router.
Tip You cannot disable an interface from the Interfaces tab while it is configured for DHCPv6 Relay.
You must first clear the DHCPv6 Relay interfaces check box and save the configuration.

Step 7 Next to a selected interface, click the drop-down icon and choose whether the interface relays DHCP requests
Upstream, Downstream, or Both.
Note You must include at least one downstream interface and one upstream interface. Choosing both
means that the interface is both downstream and upstream.

Step 8 In the Max Hops field, enter the maximum number of hops from 1 to 255

Firepower Management Center Configuration Guide, Version 6.3

1290
 7000 and 8000 Series Advanced Deployment Options
Static Routes

Step 9 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Static Routes
Static routing allows you to write rules about the IP addresses of traffic passing through a router. It is the
simplest way of configuring path selection of a virtual router because there is no communication with other
routers regarding the current topology of the network.
Do not configure routing to IP interfaces for DHCPv4 servers that the assigned virtual router cannot route
packets to. Doing so will render previously specified routable DHCP4 servers unroutable.
The Static Routes table includes summary information about each route, as described in the following table.

Table 89: Static Routes Table View Fields

Field Description

Enabled Specifies whether this route is currently enabled or

disabled.

Name The name of the static route.

Destination The destination network where traffic is routed.

Type Specifies the action that is taken for this route, which
will is one of the following:
• IP — designates that the route forwards packets
to the address of a neighboring router.
• Interface — designates that the route forwards
packets to an interface through which traffic is
routed to hosts on a directly connected network.
• Discard — designates that the static route drops
packets.

Gateway The target IP address if you selected IP as the static

route type or the interface if you selected Interface as
the static route type.

Preference Determines the route selection. If you have multiple

routes to the same destination, the system selects the
route with the higher preference.

Firepower Management Center Configuration Guide, Version 6.3

1291
 7000 and 8000 Series Advanced Deployment Options
Viewing the Static Routes Table

Viewing the Static Routes Table

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Any Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to view, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router where you want to view static routes, click the edit icon ( ).

If a view icon ( ) appears instead, the configuration belongs to a descendant domain, or you do not have
permission to modify the configuration.

Step 5 Click the Static tab.

Adding Static Routes

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to add the static route, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router where you want to add the static route, click the edit icon ( ).
Step 5 Click Static to display the static route options.
Step 6 Click Add Static Route.
Step 7 In the Route Name field, enter a name for the static route. You can use alphanumeric characters and spaces.
Step 8 For Enabled, check the check box to specify that the route is currently enabled.
Step 9 In the Preference field, enter a numerical value between 1 and 65535 to determine the route selection.

Firepower Management Center Configuration Guide, Version 6.3

1292
 7000 and 8000 Series Advanced Deployment Options
Dynamic Routing

Note If you have multiple routes to the same destination, the system uses the route with the higher
preference.

Step 10 From the Type drop-down list, choose the type of static route you are configuring.
Step 11 In the Destination field, enter the IP address for the destination network where traffic should be routed.
Step 12 In the Gateway field, you have two options:
• If you chose IP as the selected static route type, choose an IP address.
• If you chose Interface as the selected static route type, choose an enabled interface from the drop-down
list.
Tip Interfaces you have disabled from the Interfaces tab are not available; disabling an interface
you have added removes it from the configuration.

Step 13 Click OK.

Step 14 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Dynamic Routing
Dynamic, or adaptive, routing uses a routing protocol to alter the path that a route takes in response to a change
in network conditions. The adaptation is intended to allow as many routes as possible to remain valid, that is,
have destinations that can be reached in response to the change. This allows the network to “route around”
damage, such as loss of a node or a connection between nodes, so long as other path choices are available.
You can configure a router with no dynamic routing, or you can configure the Routing Information Protocol
(RIP) or the Open Shortest Path First (OSPF) routing protocol.

RIP Configuration
Routing Information Protocol (RIP) is a dynamic routing protocol, designed for small IP networks, that relies
on hop count to determine routes. The best routes use the fewest number of hops. The maximum number of
hops allowed for RIP is 15. This hop limit also limits the size of the network that RIP can support.

Adding Interfaces for RIP Configuration

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

While configuring RIP, you must choose interfaces from those already included in the virtual router, where
you want to configure RIP. Disabled interfaces are not available.

Firepower Management Center Configuration Guide, Version 6.3

1293
 7000 and 8000 Series Advanced Deployment Options
Configuring Authentication Settings for RIP Configuration

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router you want to modify, click the edit icon ( ).
Step 5 Click Dynamic Routing to display the dynamic routing options.
Step 6 Click RIP to display the RIP options.

Step 7 Under Interfaces, click the add icon ( ).

Step 8 From the Name drop-down list, choose the interface where you want to configure RIP.
Tip Interfaces you have disabled from the Interfaces tab are not available; disabling an interface you
have added removes it from the configuration.

Step 9 In the Metric field, enter a metric for the interface. When routes from different RIP instances are available
and all of them have the same preference, the route with the lowest metric becomes the preferred route.
Step 10 From the Mode drop-down list, choose one of the following options:
• Multicast — default mode where RIP multicasts the entire routing table to all adjacent routers at a
specified address.
• Broadcast — forces RIP to use broadcast (for example, RIPv1) even though multicast mode is possible.
• Quiet — RIP will not transmit any periodic messages to this interface.
• No Listen — RIP will send to this interface but not listen to it.

Step 11 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring Authentication Settings for RIP Configuration

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

RIP authentication uses one of the authentication profiles you configured on the virtual router.

Firepower Management Center Configuration Guide, Version 6.3

1294
 7000 and 8000 Series Advanced Deployment Options
Configuring Advanced Settings for RIP Configuration

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router where you want to add the RIP authentication profile, click the edit icon ( ).
Step 5 Click Dynamic Routing to display the dynamic routing options.
Step 6 Click RIP to display the RIP options.
Step 7 Under Authentication, choose an existing virtual router authentication profile from the Profile drop-down
list, or choose None.
Step 8 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring Advanced Settings for RIP Configuration

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can configure several advanced RIP settings pertaining to various timeout values and other features that
affect the behavior of the protocol.

Caution Changing any of the advanced RIP settings to incorrect values can prevent the router from communicating
successfully with other RIP routers.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router you want to modify, click the edit icon ( ).
Step 5 Click Dynamic Routing to display the dynamic routing options.
Step 6 Click RIP to display the RIP options.

Firepower Management Center Configuration Guide, Version 6.3

1295
 7000 and 8000 Series Advanced Deployment Options
Adding Import Filters for RIP Configuration

Step 7 In the Preference field, enter a numerical value (higher is better) for the preference of the routing protocol.
The system prefers routes learned through RIP over static routes.
Step 8 In the Period field, enter the interval, in seconds, between periodic updates. A lower number determines faster
convergence, but larger network load.
Step 9 In the Timeout Time field, enter a numerical value that specifies how old routes must be, in seconds, before
being considered unreachable.
Step 10 In the Garbage Time field, enter a numerical value that specifies how old routes must be, in seconds, before
being discarded.
Step 11 In the Infinity field, enter a numerical value that specifies a value for infinity distance in convergence
calculations. Larger values will make protocol convergence slower.
Step 12 From the Honor drop-down list, choose one of the following options to designate when requests for dumping
routing tables should be honored:
• Always — always honor requests
• Neighbor — only honor requests sent from a host on a directly connected network
• Never — never honor requests

Step 13 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Adding Import Filters for RIP Configuration

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can add an import filter to designate which routes are accepted or rejected from RIP into the route table.
Import filters are applied in the order they appear in the table.
When adding an import filter, you use one of the filters you configured on the virtual router.

Tip
To edit a RIP import filter, click the edit icon ( ). To delete a RIP import filter, click the delete icon ( ).

Before you begin

• Add a virtual router as described in Adding Virtual Routers, on page 1288.
• Configure a filter on the virtual router as described in Setting Up Virtual Router Filters, on page 1307.

Firepower Management Center Configuration Guide, Version 6.3

1296
 7000 and 8000 Series Advanced Deployment Options
Adding Export Filters for RIP Configuration

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router where you want to add the RIP virtual router filter, click the edit icon ( ).
Step 5 Click Dynamic Routing to display the dynamic routing options.
Step 6 Click RIP to display the RIP options.

Step 7 Under Import Filters, click the add icon ( ).

Step 8 From the Name drop-down list, choose the filter you want to add as an import filter.
Step 9 Next to Action, choose Accept or Reject.
Step 10 Click OK.
Tip
To change the order of the import filters, click the move up ( ) and move down ( ) icons as
needed. You can also drag the filters up or down in the list.

Step 11 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Adding Export Filters for RIP Configuration

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can add an export filter to define which routes will be accepted or rejected from the route table to RIP.
Export filters are applied in the order they appear in the table.
When adding an export filter, you use one of the filters you configured on the virtual router.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Firepower Management Center Configuration Guide, Version 6.3

1297
 7000 and 8000 Series Advanced Deployment Options
OSPF Configuration

Step 4 Next to the virtual router where you want to add the RIP virtual router filter, click the edit icon ( ).
Step 5 Click Dynamic Routing to display the dynamic routing options.
Step 6 Click RIP to display the RIP options.

Step 7 Under Export Filters, click the add icon ( ).

Step 8 From the Name drop-down list, choose the filter you want to add as an export filter.
Step 9 Next to Action, choose Accept or Reject.
Step 10 Click OK.
Tip
To change the order of the export filters, click the move up ( ) and move down ( ) icons as
needed. You can also drag the filters up or down in the list.

Step 11 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

OSPF Configuration
Open Shortest Path First (OSPF) is an adaptive routing protocol that defines routes dynamically by obtaining
information from other routers and advertising routes to other routers using link state advertisements. The
router keeps information about the links between it and the destination to make routing decisions. OSPF
assigns a cost to each routed interface, and considers the best routes to have the lowest costs.

OSPF Routing Areas

An OSPF network may be structured, or subdivided, into routing areas to simplify administration and optimize
traffic and resource use. Areas are identified by 32-bit numbers, expressed either simply in decimal or often
in octet-based dot-decimal notation.
By convention, area zero or 0.0.0.0 represents the core or backbone region of an OSPF network. You may
choose to identify other areas. Often, administrators select the IP address of a main router in an area as the
area's identification. Each additional area must have a direct or virtual connection to the backbone OSPF area.
Such connections are maintained by an interconnecting router, known as the area border router (ABR). An
ABR maintains separate link state databases for each area it serves and maintains summarized routes for all
areas in the network.

Adding OSPF Areas

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

Firepower Management Center Configuration Guide, Version 6.3

1298
 7000 and 8000 Series Advanced Deployment Options
OSPF Area Interfaces

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router you want to modify, click the edit icon ( ).
Step 5 Click Dynamic Routing to display the dynamic routing options.
Step 6 Click OSPF to display the OSPF options.

Step 7 Under Areas, click the add icon ( ).

Step 8 In the Area Id field, enter a numerical value for the area. This value can be either an integer or an IPv4 address.
Step 9 Optionally, check the Stubnet check box to designate that the area does not receive router advertisements
external to the autonomous system and routing from within the area is based entirely on a default route. If
you clear the check box, the area becomes a backbone area or otherwise non-stub area.
Step 10 In the Default cost field, enter a cost associated with the default route for the area.

Step 11 Under Stubnets, click the add icon ( ).

Step 12 In the IP Address field, enter an IP address in CIDR notation.
Step 13 Choose the Hidden check box to indicate that the stubnet is hidden.
Hidden stubnets are not propagated into other areas.

Step 14 Choose the Summary check box to designate that default stubnets that are subnetworks of this stubnet are
suppressed.
Step 15 In the Stub cost field, enter a value that defines the cost associated with routing to this stub network.
Step 16 Click OK.

Step 17 If you want to add a network, click the add icon ( ) under Networks.
Step 18 In the IP Address field, enter an IP address in CIDR notation for the network.
Step 19 Check the Hidden check box to indicate that the network is hidden. Hidden networks are not propagated into
other areas.
Step 20 Click OK.
Step 21 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

OSPF Area Interfaces

You can configure a subset of the interfaces assigned to the virtual router for OSPF. The following list describes
the options you can specify on each interface.

Firepower Management Center Configuration Guide, Version 6.3

1299
 7000 and 8000 Series Advanced Deployment Options
OSPF Area Interfaces

Interfaces
Select the interface where you want to configure OSPF. Interfaces you have disabled from the Interfaces tab
are not available.

Type
Select the type of OSPF interface from the following choices:
• Broadcast — On broadcast networks, flooding and hello messages are sent using multicasts, a single
packet for all the neighbors. The option designates a router to be responsible for synchronizing the link
state databases and originating network link state advertisements. This network type cannot be used on
physically non-broadcast multiple-access (NBMP) networks and on unnumbered networks without proper
IP prefixes.
• Point-to-Point (PtP) — Point-to-point networks connect just two routers together. No election is performed
and no network link state advertisement is originated, which makes it simpler and faster to establish.
This network type is useful not only for physically PtP interfaces, but also for broadcast networks used
as PtP links. This network type cannot be used on physically NBMP networks.
• Non-Broadcast — On NBMP networks, the packets are sent to each neighbor separately because of the
lack of multicast capabilities. Similar to broadcast networks, the option designates a router, which plays
a central role in the propagation of link state advertisements. This network type cannot be used on
unnumbered networks.
• Autodetect — The system determines the correct type based on the specified interface.

Cost
Specify the output cost of the interface.

Stub
Specify whether the interface should listen for OSPF traffic and transmit its own traffic.

Priority
Enter a numerical value that specifies the priority value used in designated router election. On every multiple
access network, the system designates a router and backup router. These routers have some special functions
in the flooding process. Higher priority increases preferences in this election. You cannot configure a router
with a priority of 0.

Nonbroadcast
Specify whether hello packets are sent to any undefined neighbors. This switch is ignored on any NBMA
network.

Authentication
Select the OSPF authentication profile that this interface uses from one of the authentication profiles you
configured on the virtual router or select None. For more information about configuring authentication profiles,
see Adding Virtual Router Authentication Profiles, on page 1308.

Firepower Management Center Configuration Guide, Version 6.3

1300
 7000 and 8000 Series Advanced Deployment Options
Adding OSPF Area Interfaces

Hello Interval
Type the interval, in seconds, between the sending of hello messages.

Poll
Type the interval, in seconds, between the sending of hello messages for some neighbors on NBMA networks.

Retrans Interval
Type the interval, in seconds, between retransmissions of unacknowledged updates.

Retrans Delay
Type the estimated number of seconds it takes to transmit a link state update packet over the interface.

Wait Time
Type the number of seconds that the router waits between starting election and building adjacency.

Dead Interval
Type the number of seconds that the router waits before declaring a neighbor down when not receiving
messages from it. If this value is defined, it overrides the value calculated from dead count.

Dead Count
Type a numerical value that when multiplied by the hello interval specifies the number of seconds that the
router waits before declaring a neighbor down when not receiving messages from it.

To edit an OSPF area interface, click the edit icon ( ). To delete an OSPF area interface, click the delete
icon ( ). Disabling a configured interface from the Interfaces tab also deletes it.

Adding OSPF Area Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Seriess Leaf only Admin/Network

Admin

You can configure a subset of the interfaces assigned to the virtual router for OSPF.
You can choose only one interface for use in an OSPF area.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to add the OSPF interface, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Firepower Management Center Configuration Guide, Version 6.3

1301
 7000 and 8000 Series Advanced Deployment Options
Adding OSPF Area Vlinks

Step 4 Next to the virtual router where you want to add the OSPF interface, click the edit icon ( ).
Step 5 Click Dynamic Routing to display the dynamic routing options.
Step 6 Click OSPF to display the OSPF options.

Step 7 Under Areas, click the add icon ( ).

Step 8 Click Interfaces.

Step 9 Click the add icon ( ).

Step 10 Take any of the actions as described in OSPF Area Interfaces, on page 1299.

Step 11 If you want to add a network, click the add icon ( ) under Networks.
Step 12 In the IP address field, enter an IP address for the neighbor receiving hello messages on non-broadcast
networks from this interface.
Step 13 Check the Eligible check box to indicate that the neighbor is eligible to receive messages.
Step 14 Click OK.
Tip
To edit a neighbor, click the edit icon ( ). To delete a neighbor, click the delete icon ( ).

Step 15 Click OK.

Step 16 Click Save.
Step 17 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Adding OSPF Area Vlinks

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

All areas in an OSPF autonomous system must be physically connected to the backbone area. In some cases
where this physical connection is not possible, you can use a vlink to connect to the backbone through a
non-backbone area. Vlinks can also be used to connect two parts of a partitioned backbone through a
non-backbone area.
You must add a minimum of two OSPF areas before you can add a vlink.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Firepower Management Center Configuration Guide, Version 6.3

1302
 7000 and 8000 Series Advanced Deployment Options
Adding Import Filters for OSPF Configuration

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router you want to modify, click the edit icon ( ).
Step 5 Click Dynamic Routing to display the dynamic routing options.
Step 6 Click OSPF to display the OSPF options.

Step 7 Under Areas, click the add icon ( ).

Step 8 Click Vlinks.

Step 9 Click the add icon ( ).

Step 10 In the Router ID field, enter an IP address for the router.
Step 11 From the Authentication drop-down list, choose the authentication profile the vlink will use.
Step 12 In the Hello Interval field, enter the interval, in seconds, between sending of hello messages.
Step 13 In the Retrans Interval field, enter the interval, in seconds, between retransmissions of unacknowledged
updates.
Step 14 In the Wait Time field, enter the number of seconds that the router waits between starting election and building
adjacency.
Step 15 In the Dead Interval field, enter the number of seconds that the router waits before declaring a neighbor down
when not receiving messages from it. If this value is defined, it overrides the value calculated from dead count.
Step 16 In the Dead Count field, enter a numerical value that when multiplied by the hello interval, specifies the
number of seconds that the router waits before declaring a neighbor down when not receiving messages from
it.
Step 17 Click OK.
Step 18 Click Save.
Step 19 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Adding Import Filters for OSPF Configuration

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can add an import filter to define which routes are accepted or rejected from OSPF into the route table.
Import filters are applied in the order they appear in the table.
When adding an import filter, you use one of the filters you configured on the virtual router.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).

Firepower Management Center Configuration Guide, Version 6.3

1303
 7000 and 8000 Series Advanced Deployment Options
Adding Export Filters for OSPF Configuration

In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click Virtual Routers.

Step 4 Next to the virtual router you want to modify, click the edit icon ( ).
Step 5 Click Dynamic Routing to display the dynamic routing options.
Step 6 Click OSPF to display the OSPF options.

Step 7 Under Import Filters, click the add icon ( ).

Step 8 From the Name drop-down list, choose the filter you want to add as an import filter.
Step 9 Next to Action, choose Accept or Reject.
Step 10 Click OK.
Tip
To change the order of the import filters, click the move up ( ) and move down ( ) icons as
needed. You can also drag the filters up or down in the list.

Step 11 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Adding Export Filters for OSPF Configuration

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can add an export filter to define which routes will be accepted or rejected from the route table to OSPF.
Export filters are applied in the order they appear in the table.
When adding an export filter, you use one of the filters you configured on the virtual router.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router where you want to add the OSPF virtual router filter, click the edit icon ( ).
Step 5 Click the Dynamic Routing tab to display the dynamic routing options.
Step 6 Click OSPF to display the OSPF options.

Step 7 Under Export Filters, click the add icon ( ).

Firepower Management Center Configuration Guide, Version 6.3

1304
 7000 and 8000 Series Advanced Deployment Options
Virtual Router Filters

Step 8 From the Name drop-down list, choose the filter you want to add as an export filter.
Step 9 Next to Action, choose Accept or Reject.
Step 10 Click OK.
Tip
To change the order of the export filters, click the move up ( ) and move down ( ) icons as
needed. You can also drag the filters up or down in the list.

Step 11 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Virtual Router Filters

Filters provide a way to match routes for importing into the virtual router’s route table and for exporting routes
to dynamic protocols. You can create and manage a list of filters. Each filter defines specific criteria to look
for in routes that are defined statically or received from a dynamic protocol.
The Virtual Routers Filters table includes summary information about each filter you have configured on a
virtual router, as described in the following table.

Table 90: Virtual Router Filters Table View Fields

Field Description

Name The name of the filter.

Protocol The protocol that the route originates from:

• Static — The route originates as a local static
route.
• RIP — The route originates from a dynamic RIP
configuration.
• OSPF — The route originates from a dynamic
OSPF configuration.

From Router The router IP addresses that this filter attempts to

match in a router. You must enter this value for static
and RIP filters.

Next Hop The next hop where packets using this route are
forwarded. You must enter this value for static and
RIP filters.

Firepower Management Center Configuration Guide, Version 6.3

1305
 7000 and 8000 Series Advanced Deployment Options
Viewing Virtual Router Filters

Field Description

Destination Type The type of destination where packets are sent:

• Router
• Device
• Discard

Destination Network The networks that this filter attempts to match in a

route.

OSPF Path Type Applies only to OSPF protocol. The path type can be
one of the following:
• Ext-1
• Ext-2
• Inter Area
• Intra Area

OSPF Router ID Applies only to OSPF protocol. The router ID of the

router advertising that route/network.

Viewing Virtual Router Filters

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Any Admin/Network

Admin

The Filter tab of the virtual router editor displays a table listing of all the filters you have configured on a
virtual router. The table includes summary information about each filter.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to view, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router where you want to view the filters, click the edit icon ( ).
Step 5 Click the Filter tab.

Firepower Management Center Configuration Guide, Version 6.3

1306
 7000 and 8000 Series Advanced Deployment Options
Setting Up Virtual Router Filters

Setting Up Virtual Router Filters

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router you want to modify, click the edit icon ( ).
Step 5 Click the Filter tab.
Step 6 Click Add Filter.
Step 7 In the Name field, enter a name for the filter. You can use alphanumeric characters only.
Step 8 Under Protocol, choose All or choose the protocol that applies to the filter.
Step 9 If you chose All, Static, or RIP as the Protocol, under From Router, enter the router IP addresses that this
filter will attempt to match in a route.
Note You can also enter a /32 CIDR block for IPv4 addresses and a /128 prefix length for IPv6 addresses.
All other address blocks are invalid for this field.

Step 10 Click Add.

Step 11 If you chose All, Static, or RIP as the Protocol, under Next Hop, enter the IP addresses for the gateways that
this filter will attempt to match in a route.
Note You can also enter a /32 CIDR block for IPv4 addresses and a /128 prefix length for IPv6 addresses.
All other address blocks are invalid for this field.

Step 12 Click Add.

Step 13 Under Destination Type, choose the options that apply to the filter.
Step 14 Under Destination Network, enter the IP address of the network that this filter will attempt to match in a
route.
Step 15 Click Add.
Step 16 If you chose All or OSPF as the Protocol, under Path Type, choose the options that apply to the filter. You
must choose at least one path type.
Step 17 If you chose OSPF as the Protocol, under Router ID, enter the IP address that serves as the router ID of the
router advertising the route/network.
Step 18 Click Add.
Step 19 Click OK.

Firepower Management Center Configuration Guide, Version 6.3

1307
 7000 and 8000 Series Advanced Deployment Options
Adding Virtual Router Authentication Profiles

Step 20 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Adding Virtual Router Authentication Profiles

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can set up Authentication Profiles for use in RIP and OSPF configurations. You can configure a simple
password or specify a shared cryptographic key. Simple passwords allow for every packet to carry eight bytes
of the password. The system ignores received packets lacking this password. Cryptographic keys allow for
validation, a 16-byte long digest generated from a password to be appended to every packet.
Note that for OSPF, each area can have a different authentication method. Therefore, you create authentication
profiles that can be shared among many areas. You cannot add authentication for OSPFv3.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router you want to modify, click the edit icon ( ).
Step 5 Click Authentication Profile.
Step 6 Click Add Authentication Profile.
Step 7 In the Authentication Profile Name field, enter a name for the authentication profile.
Step 8 From the Authentication Type drop down list, choose simple or cryptographic.
Step 9 In the Password field, enter a secure password.
Step 10 In the Confirm Password field, enter the password again to confirm it.
Step 11 Click OK.
Step 12 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1308
 7000 and 8000 Series Advanced Deployment Options
Viewing Virtual Router Statistics

Viewing Virtual Router Statistics

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Any Admin/Network

Admin

You can view runtime statistics for each virtual router. The statistics display unicast packets, packets dropped,
and separate routing tables for IPv4 and IPv6 addresses.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to view statistics, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router where you want to view the router statistics, click the view icon ( ).

Deleting Virtual Routers

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

When you delete a virtual router, any routed interfaces assigned to the router become available for inclusion
in another router.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device you want to modify, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Click the Virtual Routers tab.

Step 4 Next to the virtual router that you want to delete, click the delete icon ( ).
Step 5 When prompted, confirm that you want to delete the virtual router.

Firepower Management Center Configuration Guide, Version 6.3

1309
 7000 and 8000 Series Advanced Deployment Options
Deleting Virtual Routers

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1310
 CHAPTER 59
Aggregate Interfaces and LACP
The following topics explain aggregate interface configuration and how LACP functions on managed devices:
• About Aggregate Interfaces, on page 1311
• LAG Configuration, on page 1312
• Link Aggregation Control Protocol (LACP), on page 1316
• Adding Aggregate Switched Interfaces, on page 1317
• Adding Aggregate Routed Interfaces, on page 1319
• Adding Logical Aggregate Interfaces, on page 1322
• Viewing Aggregate Interface Statistics, on page 1323
• Deleting Aggregate Interfaces, on page 1323

About Aggregate Interfaces

In the Firepower System, you can group multiple physical Ethernet interfaces into a single logical link on
managed devices configured in either a Layer 2 deployment that provides packet switching between networks,
or a Layer 3 deployment that routes traffic between interfaces. This single aggregate logical link provides
higher bandwidth, redundancy, and load-balancing between two endpoints.
You create aggregate links by creating a switched or routed link aggregation group, or LAG. When you create
an aggregation group, a logical interface called an aggregate interface is created. To an upper layer entity a
LAG looks like a single logical link and data traffic is transmitted through the aggregate interface. The
aggregate link provides increased bandwidth by adding the bandwidth of multiple links together. It also
provides redundancy by load-balancing traffic across all available links. If one link fails, the system
automatically load-balances traffic across all remaining links.

The endpoints in a LAG can be two 7000 or 8000 Series devices, as shown in the illustration above, or a 7000
or 8000 Series device connected to a third-party access switch or router. The two devices do not have to match,
but they must have the same physical configuration and they must support the IEEE 802.ad link aggregation
standard. A typical deployment for a LAG might be to aggregate access links between two managed devices,
or to create a point-to-point connection between a managed device and an access switch or a router.
Note that you cannot configure aggregate interfaces on NGIPSv devices or ASA FirePOWER modules.

Firepower Management Center Configuration Guide, Version 6.3

1311
 7000 and 8000 Series Advanced Deployment Options
LAG Configuration

LAG Configuration
There are two types of aggregate interfaces:
• switched — Layer 2 aggregate interfaces
• routed — Layer 3 aggregate interfaces

You implement link aggregation through the use of link aggregation groups (LAGs). You configure a LAG
by creating an aggregate switched or routed interface and then associating a set of physical interfaces with
the link. All of the physical interfaces must be of the same speed and medium.
You create aggregate links either dynamically or statically. Dynamic link aggregation uses Link Aggregation
Control Protocol (LACP), a component of the IEEE 802.ad link aggregation standard, while static link
aggregation does not. LACP enables each device on either end of the LAG to exchange link and system
information to determine which links will be actively used in the aggregation. A static LAG configuration
requires you to manually maintain link aggregations and deploy load-balancing and link selection policies.
When you create a switched or routed aggregate interface, a link aggregation group of the same type is created
and numbered automatically. For example, when you create your first LAG (switched or routed), the aggregate
interface can be identified by the lag0 label in the Interfaces tab for your managed device. When you associate
physical and logical interfaces with this LAG, they appear nested below the primary LAG in a hierarchical
tree menu. Note that a switched LAG can only contain switched physical interfaces, and a routed LAG can
only contain routed physical interfaces.
Consider the following requirements when you configure a LAG:
• The Firepower System supports a maximum of 14 LAGs, and assigns a unique ID to each LAG interface
in the range of 0 to 13. The LAG ID is not configurable.
• You must configure the LAG on both sides of the link, and you must set the interfaces on either side of
the link to the same speed.
• You must associate at least two physical interfaces per LAG, up to a maximum of eight. A physical
interface cannot belong to more than one LAG.
• Physical interfaces in a LAG cannot be used in any other mode of operation, either as inline or passive,
or be used as part of another logical interface for tagged traffic.
• Physical interfaces in a LAG can span multiple NetMods, but cannot span multiple sensors (i.e. all
physical interfaces must reside on the same device).
• A LAG cannot contain a stacking NetMod.

Aggregate Switched Interfaces

You can combine between two and eight physical ports on a managed device to create a switched LAG
interface. You must assign a switched LAG interface to a virtual switch before it can handle traffic. A managed
device can support up to 14 LAG interfaces.
The range of MTU values can vary depending on the model of the managed device and the interface type.

Firepower Management Center Configuration Guide, Version 6.3

1312
 7000 and 8000 Series Advanced Deployment Options
Aggregate Routed Interfaces

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 312 for more information.

Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Aggregate Routed Interfaces

You can combine between two and eight physical ports on a7000 or 8000 Series device to create a routed
LAG interface. You must assign a routed LAG interface to a virtual router before it can route traffic. A
managed device can support up to 14 LAG interfaces.
You can add static Address Resolution Protocol (ARP) entries to a routed LAG interface. If an external host
needs to know the MAC address of the destination IP address it needs to send traffic to on your local network,
it sends an ARP request. When you configure static ARP entries, the virtual router responds with an IP address
and associated MAC address.
Disabling the ICMP Enable Responses option for routed LAG interfaces does not prevent ICMP responses
in all scenarios. You can still use access control rules to handle connections where the destination IP is the
routed interface’s IP and the protocol is ICMP; see Port and ICMP Code Conditions, on page 332.
If you enable the Inspect Local Router Traffic option, the system blocks packets before they reach the host,
thereby preventing any response. For more information about inspecting local router traffic, see Advanced
Device Settings, on page 504.
The range of MTU values can vary depending on the model of the managed device and the interface type.

Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 312 for more information.

Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Logical Aggregate Interfaces

For each switched or routed aggregate interface, you can add multiple logical interfaces. You must associate
each logical LAG interface with a VLAN tag to handle traffic received by the LAG interface with that specific
tag. You add logical interfaces to switched or routed aggregate interfaces in the same way you would add
them to physical switched or routed interfaces.

Firepower Management Center Configuration Guide, Version 6.3

1313
 7000 and 8000 Series Advanced Deployment Options
Load-Balancing Algorithms

Note When you create a LAG interface you also create an “untagged” logical interface by default, which is identified
by the lagn.0 label, where n is an integer from 0 to 13. To be operational, each LAG requires this one logical
interface at a minimum. You can associate additional logical interfaces with any LAG to handle VLAN-tagged
traffic. Each additional logical interface requires a unique VLAN tag. The Firepower System supports VLAN
tags in the range of 1 through 4094.

You can also configure the Cisco Redundancy Protocol (SFRP) on a logical routed interface. SFRP allows
devices to act as redundant gateways for specified IP addresses.
Note that disabling the ICMP Enable Responses option for logical routed interfaces does not prevent ICMP
responses in all scenarios. You can add network-based rules to an access control policy to drop packets where
the destination IP is the routed interface’s IP and the protocol is ICMP.
If you have enabled the Inspect Local Router Traffic option, which is an advanced setting on the managed
device, it drops the packets before they reach the host, thereby preventing any response.
The range of MTU values can vary depending on the model of the managed device and the interface type.

Caution Changing the highest MTU value among all non-management interfaces on the device restarts the Snort
process when you deploy configuration changes, temporarily interrupting traffic inspection. Inspection is
interrupted on all non-management interfaces, not just the interface you modified. Whether this interruption
drops traffic or passes it without further inspection depends on the model of the managed device and the
interface type. See Snort® Restart Traffic Behavior, on page 312 for more information.

Related Topics
SFRP
Advanced Device Settings, on page 504
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Load-Balancing Algorithms
You assign an egress load-balancing algorithm to the LAG that determines how to distribute traffic to the
LAG bundle’s member links. The load-balancing algorithm makes hashing decisions based on values in
various packet fields, such as Layer 2 MAC addresses, Layer 3 IP addresses, and Layer 4 port numbers
(TCP/UDP traffic). The load-balancing algorithm you select applies to all of the LAG bundle’s member links.
Choose the load-balancing algorithm that supports your deployment scenario from the following options when
you configure a LAG:
• Destination IP
• Destination MAC
• Destination Port
• Source IP
• Source MAC

Firepower Management Center Configuration Guide, Version 6.3

1314
 7000 and 8000 Series Advanced Deployment Options
Link Selection Policies

• Source Port
• Source and Destination IP
• Source and Destination MAC
• Source and Destination Port

Note You should configure both ends of the LAG to have the same load-balancing
algorithm. Higher layer algorithms will back off to lower layer algorithms as
necessary (such as a Layer 4 algorithm backing off to Layer 3 for ICMP traffic).

Link Selection Policies

Link aggregation requires the speed and medium of each link to be the same at both endpoints. Because link
properties can change dynamically, the link selection policy helps determine how the system manages the
link selection process. A link selection policy that maximizes the highest port count supports link redundancy,
while a link selection policy that maximizes total bandwidth supports overall link speed. A stable link selection
policy attempts to minimize excessive changes in link states.

Note You should configure both ends of the LAG to have the same link selection policy.

Choose the link selection policy that supports your deployment scenario from the following options:
• Highest Port Count — Choose this option for the highest total active port count to provide added
redundancy.
• Highest Total Bandwidth — Choose this option to provide the highest total bandwidth for the aggregated
link.
• Stable — Choose this option if your primary concern is link stability and reliability. Once you configure
a LAG, the active links change only when absolutely necessary (such as link failure) rather than doing
so for added port count or bandwidth.
• LACP Priority — Choose this option to use the LACP algorithm to determine which links are active in
the LAG. This setting is appropriate if you have undefined deployment goals, or if the device at the other
end of the LAG is not managed by the Firepower Management Center.

LACP is a key aspect of automating the link selection method that supports dynamic link aggregation. When
LACP is enabled, a link selection policy based on LACP priority uses the following properties of LACP:
LACP system priority
You configure this value on each partnered device running LACP to determine which one is superior in
link aggregation. The system with the lower value has the higher system priority. In dynamic link
aggregation, the system with the higher LACP system priority sets the selected state of member links on
its side first, then the system with the lower priority sets its member links accordingly. You can specify
0 to 65535. If you do not specify a value, the default priority is 32768.

Firepower Management Center Configuration Guide, Version 6.3

1315
 7000 and 8000 Series Advanced Deployment Options
Link Aggregation Control Protocol (LACP)

LACP link priority

You configure this value on each link belonging to the aggregation group. The link priority determines
the active and standby links in the LAG. Links with lower values have higher priority. If an active link
goes down, the standby link with the highest priority is selected to replace the downed link. However,
if two or more links have the same LACP link priority, the link with the lowest physical port number is
selected as the standby link. You can specify 0 to 65535. If you do not specify a value, the default priority
is 32768.

Link Aggregation Control Protocol (LACP)

Link Aggregation Control Protocol (LACP), a component of IEEE 802.3ad, is a method of exchanging system
and port information to create and maintain LAG bundles. When you enable LACP, each device on either
end of the LAG uses LACP to determine which links will be actively used in the aggregation. LACP provides
availability and redundancy by exchanging LACP packets (or control messages) between links. It learns the
capabilities of the links dynamically and informs the other links. Once LACP identifies correctly matched
links, it facilitates grouping the links into the LAG. If a link fails, traffic continues on the remaining links.
LACP must be enabled at both ends of the LAG for the link to be operational.

LACP
When you enable LACP, you need to specify a transmission mode for each end of the LAG that determines
how LACP packets are exchanged between partnered devices. There are two options for LACP mode:
• Active — Choose this mode to place a device into an active negotiating state, in which the device initiates
negotiations with remote links by sending LACP packets.
• Passive — Choose this mode to place a device into a passive negotiating state, in which the device
responds to LACP packets it receives but does not initiate LACP negotiation.

Note Both modes allow LACP to negotiate between links to determine if they can form
a link bundle based on criteria such as port speed. However, you should avoid a
passive-passive configuration, which essentially places both ends of the LAG in
listening mode.

LACP has a timer which defines how often LACP packets are sent between devices. LACP exchanges packets
at these rates:
• Slow — 30 seconds
• Fast — 1 second

The device where this option is applied expects to receive LACP packets with this frequency from the partner
device on the other side of the LAG.

Firepower Management Center Configuration Guide, Version 6.3

1316
 7000 and 8000 Series Advanced Deployment Options
Adding Aggregate Switched Interfaces

Note When a LAG is configured on a managed device that is part of a device stack, only the primary device
participates in LACP communication with the partner system. All secondary devices forward LACP messages
to the primary device. The primary device relays any dynamic LAG modifications to the secondary devices.

Adding Aggregate Switched Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can combine between two and eight physical ports on a managed device to create a switched LAG
interface. You must assign a switched LAG interface to a virtual switch before it can handle traffic. A managed
device can support up to 14 LAG interfaces.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Click the edit icon ( ) next to the device where you want to configure the switched LAG interface.
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Choose Add Aggregate Interface from the Add drop-down menu.
Step 4 Click Switched to display the switched LAG interface options.
Step 5 If you want to apply 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 380.

Step 6 Specify a virtual switch:

• Choose an existing virtual switch from the Virtual Switch drop-down list.
• Choose New to add a new virtual switch; see Adding Virtual Switches, on page 1275.

Step 7 Check the Enabled check box to allow the switched LAG interface to handle traffic.
If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.

Step 8 From the Mode, choose an option to designate the link mode, or choose Autonegotiation to specify that the
interface is configured to auto negotiate speed and duplex settings.
Mode settings are available only for copper interfaces.
Interfaces on 8000 Series appliances do not support half-duplex options. When links auto negotiate speed, all
active links are selected for the LAG based on the same speed setting.

Firepower Management Center Configuration Guide, Version 6.3

1317
 7000 and 8000 Series Advanced Deployment Options
Adding Aggregate Switched Interfaces

Step 9 From the MDI/MDIX drop-down list, choose an option to designate whether the interface is configured for
MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
MDI/MDIX settings are available only for copper interfaces.
By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and
MDIX to attain link.

Step 10 Enter a maximum transmission unit (MTU) in the MTU field.

The range within which you can set the MTU can vary depending on the Firepower System device model and
interface type. See MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532 for more
information.

Step 11 Under Link Aggregation, choose one or more physical interfaces from Available Interfaces to add to the
LAG bundle.
Tip To remove physical interfaces from the LAG bundle, choose one or more physical interfaces and
click the remove selected icon ( ). To remove all physical interfaces from the LAG bundle, click
the remove all icon ( ). Deleting the LAG interface from the Interfaces tab also removes the
interfaces.

Step 12 Choose an option from the Load-Balancing Algorithm drop-down list.

Step 13 Choose a Link Selection Policy from the drop-down list.
Tip Choose LACP Priority if you are configuring an aggregate interface between a Firepower System
device and a third-party network device.

Step 14 If you chose LACP Priority as the Link Selection Policy, assign a value for System Priority and click the
Configure Interface Priority link to assign a priority value for each interface in the LAG.
Step 15 Choose either Inner or Outer from the Tunnel Level drop-down list.
Note The tunnel level only applies to IPv4 traffic when Layer 3 load balancing is configured. The outer
tunnel is always used for Layer 2 and IPv6 traffic. If the Tunnel Level is not explicitly set, the
default is Outer.

Step 16 Under LACP, check the Enabled check box to allow the switched LAG interface to handle traffic using the
Link Aggregation Control Protocol.
If you clear the check box, the LAG interface becomes a static configuration and the Firepower System will
use all of the physical interfaces selected for the aggregation.

Step 17 Click a Rate radio button to set the frequency that determines how often LACP control messages are received
from the partner device:
• Click Slow to receive packets every 30 seconds.
• Click Fast to receive packets every 1 second.

Step 18 Click a Mode radio button to establish the listening mode of the device:
• Click Active to initiate negotiations with remote links by sending LACP packets to the partner device.
• Click Passive to respond to LACP packets received.

Step 19 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1318
 7000 and 8000 Series Advanced Deployment Options
Adding Aggregate Routed Interfaces

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Adding Aggregate Routed Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can combine between two and eight physical ports on a managed device to create a routed LAG interface.
You must assign a routed LAG interface to a virtual router before it can route traffic. A managed device can
support up to 14 LAG interfaces.

Caution Adding a routed interface pair on 7000 or 8000 Series devices 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 312 for more information.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Click the edit icon ( ) next to the device where you want to configure the routed LAG interface.
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Choose Add Aggregate Interface from the Add drop-down menu.
Step 4 Click Routed to display the routed LAG interface options.
Step 5 If you want to apply 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 380.

Step 6 Specify a virtual router:

• Choose an existing virtual router from the Virtual Router drop-down list.
• Choose New to add a new virtual router; Adding Virtual Routers, on page 1288.

Step 7 Check the Enabled check box to allow the routed LAG interface to handle traffic.
If you clear the check box, the interface becomes disabled so that users cannot access it for security purposes.

Firepower Management Center Configuration Guide, Version 6.3

1319
 7000 and 8000 Series Advanced Deployment Options
Adding Aggregate Routed Interfaces

Step 8 From the Mode drop-down list, choose an option to designate the link mode, or choose Autonegotiation to
specify that the LAG interface is configured to auto negotiate speed and duplex settings.
Mode settings are available only for copper interfaces.
Interfaces on 8000 Series appliances do not support half-duplex options. When links auto negotiate speed, all
active links are selected for the LAG based on the same speed setting.

Step 9 Choose an option from the MDI/MDIX drop-down list to designate whether the interface is configured for
MDI (medium dependent interface), MDIX (medium dependent interface crossover), or Auto-MDIX.
MDI/MDIX settings are available only for copper interfaces.
By default, MDI/MDIX is set to Auto-MDIX, which automatically handles switching between MDI and
MDIX to attain link.

Step 10 Enter a maximum transmission unit (MTU) in the MTU field.

The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 312 for
more information.

Step 11 If you want to allow the LAG interface to respond to ICMP traffic such as pings and traceroute, check the
Enable Responses check box next to ICMP.
Step 12 If you want to enable the LAG interface to broadcast router advertisements, check the Enable Router
Advertisement check box next to IPv6 NDP.
Step 13 Click Add to add an IP address.
Step 14 In the Address field, enter the routed LAG interface’s IP address and subnet mask using CIDR notation.
Note the following:
• You cannot add network and broadcast addresses, or the static MAC addresses 00:00:00:00:00:00 and
FF:FF:FF:FF:FF:FF.
• You cannot add identical IP addresses, regardless of subnet mask, to interfaces in virtual routers.

Step 15 If your organization uses IPv6 addresses and you want to set the IP address of the LAG interface automatically,
check the Address Autoconfiguration check box next to the IPv6 field.
Step 16 For Type, choose either Normal or SFRP.
Step 17 If you chose SFRP for Type, set options as described in SFRP.
Step 18 Click OK.
Note When adding an IP address to a routed interface of a 7000 or 8000 Series device in a high-availability
pair, you must add a corresponding IP address to the routed interface on the high-availability peer.

Step 19 Click Add to add a static ARP entry.

Step 20 Enter an IP address the IP Address field.
Step 21 Enter a MAC address to associate with the IP address in the MAC Address field. Use the standard format
(for example, 01:23:45:67:89:AB).

Firepower Management Center Configuration Guide, Version 6.3

1320
7000 and 8000 Series Advanced Deployment Options
Adding Aggregate Routed Interfaces

Step 22 Click OK.

Step 23 Under Link Aggregation, choose one or more physical interfaces from Available Interfaces to add to the
LAG bundle.
Tip To remove physical interfaces from the LAG bundle, choose one or more physical interfaces and
click the remove selected icon ( ). To remove all physical interfaces from the LAG bundle, click
the remove all icon ( ). Deleting the LAG interface from the Interfaces tab also removes the
interfaces.

Step 24 Choose a Load-Balancing Algorithm from the drop-down list.

Step 25 Choose a Link Selection Policy from the drop-down list.
Tip Choose LACP Priority if you are configuring an aggregate interface between a Firepower System
device and a third-party network device.

Step 26 If you chose LACP Priority as the Link Selection Policy, assign a value for System Priority and click the
Configure Interface Priority link to assign a priority value for each interface in the LAG.
Step 27 Choose either Inner or Outer from the Tunnel Level drop-down list.
Note The tunnel level only applies to IPv4 traffic when Layer 3 load balancing is configured. The outer
tunnel is always used for Layer 2 and IPv6 traffic. If the Tunnel Level is not explicitly set, the
default is Outer.

Step 28 Under LACP, check the Enabled check box to allow the routed LAG interface to handle traffic using the
Link Aggregation Control Protocol.
If you clear the check box, the LAG interface becomes a static configuration and the Firepower System will
use all of the physical interfaces for the aggregation.

Step 29 Click a Rate radio button to set the frequency that determines how often LACP control messages are received
from the partner device.
• Click Slow to receive packets every 30 seconds.
• Click Fast to receive packets every 1 second.

Step 30 Click a Mode radio button to establish the listening mode of the device.
• Click Active to initiate negotiations with remote links by sending LACP packets to the partner device.
• Click Passive to respond to LACP packets received.

Step 31 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Advanced Device Settings, on page 504

Firepower Management Center Configuration Guide, Version 6.3

1321
 7000 and 8000 Series Advanced Deployment Options
Adding Logical Aggregate Interfaces

Adding Logical Aggregate Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

For each switched or routed aggregate interface, you can add multiple logical interfaces. You must associate
each logical LAG interface with a VLAN tag to handle traffic received by the LAG interface with that specific
tag. You add logical interfaces to switched or routed aggregate interfaces in the same way you would add
them to physical switched or routed interfaces.

Note When you create a LAG interface you also create an “untagged” logical interface by default, which is identified
by the lagn.0 label, where n is an integer from 0 to 13. To be operational, each LAG requires this one logical
interface at a minimum. You can associate additional logical interfaces with any LAG to handle VLAN-tagged
traffic. Each additional logical interface requires a unique VLAN tag. The Firepower System supports VLAN
tags in the range of 1 through 4094.

Caution Adding a routed interface pair on 7000 or 8000 Series devices 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 312 for more information.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to add the logical LAG interface, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 From the Add drop-down menu, choose Add Logical Interface.
Step 4 Click Switched to display the switched interface options, or click Routed to display the routed interface
options.
Step 5 Choose an available LAG from the Interface drop-down list. The aggregate interface is identified by the lagn
label, where n is an integer from 0 to 13.
Step 6 Configure the remaining settings appropriate to the interface type you chose:
• Switched — See Adding Logical Switched Interfaces, on page 1272 for more information on adding a
logical interface to a switched interface.
• Routed — See Adding Logical Routed Interfaces, on page 1283 for more information on adding a logical
interface to a routed interface.

Firepower Management Center Configuration Guide, Version 6.3

1322
 7000 and 8000 Series Advanced Deployment Options
Viewing Aggregate Interface Statistics

Related Topics
SFRP
Advanced Device Settings, on page 504
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Viewing Aggregate Interface Statistics

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

You can view protocol and traffic statistics for each aggregate interface. The statistics show LACP protocol
information such as LACP key and partner information, packets received, packets transmitter, and packets
dropped. Statistics are further refined per member interface to show traffic and link information on a per-port
basis.
Aggregate interface information is also presented to the dashboard via predefined dashboard widgets. The
Current Interface Status widget shows the status of all interfaces on the appliance, enabled or unused. The
Interface Traffic widget shows the rate of traffic received (Rx) and transmitted (Tx) on the appliance’s interfaces
over the dashboard time range. See Predefined Dashboard Widgets, on page 220.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to view the logical aggregate interface statistics, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Next to the interface where you want to view the interface statistics, click the view icon ( ).

Deleting Aggregate Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

The aggregate interface can be identified by the lagn label, where n can be an integer from 0 to 13.

Procedure

Step 1 Choose Devices > Device Management.

Firepower Management Center Configuration Guide, Version 6.3

1323
 7000 and 8000 Series Advanced Deployment Options
Deleting Aggregate Interfaces

Step 2 Next to the device where you want to delete the aggregate interface, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Next to the aggregate interface you want to delete, click the delete icon ( ).
Step 4 When prompted, confirm that you want to delete the aggregate interface.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1324
 CHAPTER 60
Hybrid Interfaces
The following topics describe how to configure local hybrid interfaces:
• About Hybrid Interfaces, on page 1325
• Logical Hybrid Interfaces, on page 1325
• Adding Logical Hybrid Interfaces, on page 1326
• Deleting Logical Hybrid Interfaces, on page 1328

About Hybrid Interfaces

You can configure logical hybrid interfaces on managed devices that allow the Firepower System to bridge
traffic between virtual routers and virtual switches. If IP traffic received on interfaces in a virtual switch is
addressed to the MAC address of an associated hybrid logical interface, the system handles it as Layer 3 traffic
and either routes or responds to the traffic depending on the destination IP address. If the system receives any
other traffic, it handles it as Layer 2 traffic and switches it appropriately. You cannot configure logical hybrid
interfaces on an NGIPSv device.
Note that hybrid interfaces that are not associated with both a virtual switch and a virtual router are not available
for routing, and do not generate or respond to traffic.

Logical Hybrid Interfaces

You must associate a logical hybrid interface with a virtual router and virtual switch to bridge traffic between
Layer 2 and Layer 3. You can only associate a single hybrid interface with a virtual switch. However, you
can associate multiple hybrid interfaces with a virtual router.
You can also configure the Cisco Redundancy Protocol (SFRP) on a logical hybrid interface. SFRP allows
devices to act as redundant gateways for specified IP addresses.
Note that disabling the ICMP Enable Responses option for hybrid interfaces does not prevent ICMP responses
in all scenarios. You can add network-based rules to an access control policy to drop packets where the
destination IP is the hybrid interface’s IP and the protocol is ICMP.
If you have enabled the Inspect Local Router Traffic option on the managed device, it drops the packets
before they reach the host, thereby preventing any response.
The range of MTU values can vary depending on the model of the managed device and the interface type.

Firepower Management Center Configuration Guide, Version 6.3

1325
 7000 and 8000 Series Advanced Deployment Options
Adding Logical Hybrid Interfaces

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 312 for more information.

Related Topics
Configuring SFRP, on page 1286
Advanced Device Settings, on page 504
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Adding Logical Hybrid Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

Caution Adding a routed interface pair on 7000 or 8000 Series devices 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 312 for more information.

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to add the hybrid interface, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 From the Add drop-down menu, choose Add Logical Interface.
Step 4 Click Hybrid to display the hybrid interface options.
Step 5 In the Name field, enter a name for the interface.
Step 6 From the Virtual Router drop-down list, choose an existing virtual router, choose None, or choose New to
add a new virtual router.
Note If you add a new virtual router, you must configure it on the Device Management page after you
finish setting up the hybrid interface. See Adding Virtual Routers, on page 1288.

Step 7 From the Virtual Switch drop-down list, choose an existing virtual switch, choose None, or choose New to
add a new virtual switch.

Firepower Management Center Configuration Guide, Version 6.3

1326
7000 and 8000 Series Advanced Deployment Options
Adding Logical Hybrid Interfaces

Note If you add a new virtual switch, you must configure it on the Device Management page after you
finish setting up the hybrid interface. See Adding Virtual Switches, on page 1275.

Step 8 Check the Enabled check box to allow the hybrid interface to handle traffic.
Note If you clear the check box, the interface becomes disabled and administratively taken down.

Step 9 In the MTU field, enter a maximum transmission unit (MTU), which designates the largest size packet allowed.
The range of MTU values can vary depending on the model of the managed device and the interface type.
Caution Changing the highest MTU value among all non-management interfaces on the device restarts the
Snort process when you deploy configuration changes, temporarily interrupting traffic inspection.
Inspection is interrupted on all non-management interfaces, not just the interface you modified.
Whether this interruption drops traffic or passes it without further inspection depends on the model
of the managed device and the interface type. See Snort® Restart Traffic Behavior, on page 312 for
more information.

Step 10 Next to ICMP, check the Enable Responses check box to allow the interface to respond to ICMP traffic such
as pings and traceroute.
Step 11 Next to IPv6 NDP, check the Enable Router Advertisement check box to enable the interface to broadcast
router advertisements. You can only enable this option if you added IPv6 addresses.
Step 12 To add an IP address, click Add.
Step 13 In the Address field, enter the IP address and subnet mask. Note the following:
• You cannot add network and broadcast addresses, or the static MAC addresses 00:00:00:00:00:00 and
FF:FF:FF:FF:FF:FF.
• You cannot add identical IP addresses, regardless of subnet mask, to interfaces in virtual routers.

Step 14 Optionally if you have IPv6 addresses, next to the IPv6 field, check the Address Autoconfiguration check
box to set the IP address of the interface automatically.
Step 15 For Type, choose either Normal or SFRP.
Step 16 If you chose SFRP for Type, set options as described in SFRP.
Step 17 Click OK.
Step 18 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
MTU Ranges for 7000 and 8000 Series Devices and NGIPSv, on page 532
Snort® Restart Scenarios, on page 311

Firepower Management Center Configuration Guide, Version 6.3

1327
 7000 and 8000 Series Advanced Deployment Options
Deleting Logical Hybrid Interfaces

Deleting Logical Hybrid Interfaces

Smart License Classic License Supported Devices Supported Domains Access

Any Control 7000 & 8000 Series Leaf only Admin/Network

Admin

Procedure

Step 1 Choose Devices > Device Management.

Step 2 Next to the device where you want to delete the logical hybrid interface, click the edit icon ( ).
In a multidomain deployment, if you are not in a leaf domain, the system prompts you to switch.

Step 3 Next to the logical hybrid interface you want to delete, click the delete icon ( ).
Step 4 When prompted, confirm that you want to delete the interface.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1328
 CHAPTER 61
Gateway VPNs
The following topics describe how to manage your VPN deployment:
• Gateway VPN Basics, on page 1329
• VPN Deployments, on page 1330
• VPN Deployment Management, on page 1332
• VPN Deployment Status, on page 1343
• VPN Statistics and Logs, on page 1344

Gateway VPN Basics

A virtual private network (VPN) is a network connection that establishes a secure tunnel between endpoints
via a public source, such as the internet or other network. You can configure the Firepower System to build
secure VPN tunnels between the virtual routers of Firepower managed devices. The system builds tunnels
using the Internet Protocol Security (IPsec) protocol suite.
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. A connection consists of the IP addresses and host names
of the two gateways, the subnets behind them, and the shared secrets for the two gateways to authenticate to
each other.
The VPN endpoints authenticate to each other with either the Internet Key Exchange (IKE) version 1 or
version 2 protocol to create a security association for the tunnel. The system uses either the IPsec authentication
header (AH) protocol or the IPsec encapsulating security payload (ESP) protocol to authenticate the data
entering the tunnel. The ESP protocol encrypts the data as well as providing the same functionality as AH.
If you have access control policies in your deployment, the system does not send VPN traffic until it has
passed through access control. In addition, the system does not send tunnel traffic to the public source when
the tunnel is down.
To configure and deploy VPN for Firepower, you must have a VPN license enabled on each of your target
managed devices. Additionally, VPN features are only available on 7000 and 8000 Series devices.

IPsec
The IPsec protocol suite defines how IP packets across a VPN tunnel are hashed, encrypted, and encapsulated
in the ESP or AH security protocol. The Firepower System uses the hash algorithm and encryption key of the
Security Association (SA), which becomes established between the two gateways by the Internet Key Exchange
(IKE) protocol.

Firepower Management Center Configuration Guide, Version 6.3

1329
 7000 and 8000 Series Advanced Deployment Options
IKE

Security associations (SA) establish shared security attributes between two devices and allow VPN endpoints
to support secure communication. An SA allows two VPN endpoints to handle the parameters for how the
VPN tunnel is secured between them.
The system uses the Internet Security Association and Key Management Protocol (ISAKMP) during the initial
phase of negotiating the IPsec connection to establish the VPN between endpoints and the authenticated key
exchange. The IKE protocol resides within ISAKMP.
The AH security protocol provides protection for packet headers and data, but it cannot encrypt them. ESP
provides encryption and protection for packets, but it cannot secure the outermost IP header. In many cases,
this protection is not required, and most VPN deployments use ESP more frequently than AH because of its
encryption capabilities. Since VPN only operates in tunnel mode, the system encrypts and authenticates the
entire packet from Layer 3 and up in the ESP protocol. ESP in tunnel mode encrypts the data as well as
providing the latter’s encryption capabilities.

IKE
The Firepower System uses the IKE protocol to mutually authenticate the two gateways against each other
as well as to negotiate the SA for the tunnel. The process consists of two phases.
IKE phase 1 establishes a secure authenticated communication channel by using the Diffie-Hellman key
exchange to generate a pre-shared key to encrypt further IKE communications. This negotiation results in a
bidirectional ISAKMP security association. The system allows you to perform the authentication using a
pre-shared key. Phase 1 operates in main mode, which seeks to protect all data during the negotiation, while
also protecting the identity of the peers.
During IKE phase 2, the IKE peers use the secure channel established in phase 1 to negotiate security
associations on behalf of IPsec. The negotiation results in a minimum of two unidirectional security associations,
one inbound and one outbound.

VPN Deployments
A VPN deployment specifies the endpoints and networks that are included in a VPN and how they connect
to each other. After you configure a VPN deployment on the Firepower Management Center, you can then
deploy it to your managed devices or devices managed by another Firepower Management Center.
The system supports three types of VPN deployments: point-to-point, star, and mesh.

Point-to-Point VPN Deployments

In a point-to-point VPN deployment, two endpoints communicate directly with each other. You configure the
two endpoints as peer devices, and either device can start the secured connection. Each of the devices in this
configuration must be a VPN-enabled managed device.
The following diagram displays a typical point-to-point VPN deployment.

Firepower Management Center Configuration Guide, Version 6.3

1330
 7000 and 8000 Series Advanced Deployment Options
Star VPN Deployments

Star VPN Deployments

In a star VPN deployment, a central endpoint (hub node) establishes a secure connection with multiple remote
endpoints (leaf nodes). Each connection between the hub node and an individual leaf node is a separate VPN
tunnel. The hosts behind any of the leaf nodes can communicate with each other through the hub node.
Star deployments 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. Star VPN deployments provide all
employees with controlled access to the organization’s network.
In a typical star deployment, the hub node is located at the main office. Leaf nodes are located at branch offices
and start most of the traffic. Each of the nodes must be a VPN-enabled managed device.
Star deployments only support IKE version 2.
The following diagram displays a typical star VPN deployment.

Firepower Management Center Configuration Guide, Version 6.3

1331
 7000 and 8000 Series Advanced Deployment Options
Mesh VPN Deployments

Mesh VPN Deployments

In a mesh VPN deployment, all endpoints can communicate with every other endpoint by an individual VPN
tunnel. The mesh deployment offers redundancy so that when one endpoint fails, the remaining endpoints can
still communicate with each other. This type of deployment 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. Each of the endpoints must be a VPN-enabled
managed device.
The following diagram displays a typical mesh VPN deployment.

VPN Deployment Management

On the VPN page (Devices > VPN > Site to Site), you can view all of your current VPN deployments by
name and the endpoints contained in the deployment. Options on this page allow you to view the status of a
VPN deployment, create a new deployment, deploy to managed devices, and edit or delete a deployment.
Note that when you register a device to a Firepower Management Center, deployed VPN deployments sync
to the Firepower Management Center during registration.
Related Topics
Managing VPN Deployments, on page 1338

Firepower Management Center Configuration Guide, Version 6.3

1332
 7000 and 8000 Series Advanced Deployment Options
VPN Deployment Options

VPN Deployment Options

When you create a new VPN deployment you must, at minimum, give it a unique name, specify a deployment
type, and designate a preshared key. You can select from three types of deployment, each containing a group
of VPN tunnels:
• Point-to-point (PTP) deployments establish a VPN tunnel between two endpoints.
• Star deployments establish a group of VPN tunnels connecting a hub endpoint to a group of leaf endpoints.
• Mesh deployments establish a group of VPN tunnels among a set of endpoints.

Only Cisco managed devices can be used as endpoints in VPN deployments. Third-party endpoints are not
supported.
You must define a pre-shared key for VPN authentication. You can specify a default key to use in all of the
VPN connections you generate in a deployment. For point-to-point deployments, you can specify a preshared
key for each endpoint pair.
In a multidomain deployment, you can configure a VPN deployment across domains; that is, you can assign
endpoints to devices that belong to different domains. In such cases, you can view but not modify the ancestor
deployment in the related descendant domains. When you drill down for deployment details, the system
displays information for devices that belong to the current domain only.

Point-to-Point VPN Deployment Options

When configuring a point-to-point VPN deployment, you define a group of endpoint pairs and then create a
VPN between the two nodes in each pair.
The following list describes the options you can specify in your deployment.
Name
Specify a unique name for the deployment.
Type
Click PTP to specify that you are configuring a point-to-point deployment.
Pre-shared Key
Define a unique pre-shared key for authentication. The system uses this key for all the VPNs in your
deployment, unless you specify a pre-shared key for each endpoint pair.
Device
You can choose a managed device, including a device stack or device high-availability pair, as an endpoint
for your deployment. For Cisco-managed devices not managed by the Firepower Management Center
you are using, choose Other and then specify an IP address for the endpoint.
Virtual Router
If you chose a managed device as your endpoint, choose a virtual router that is currently applied to the
selected device. You cannot choose the same virtual router for more than one endpoint.
Interface
If you chose a managed device as your endpoint, choose a routed interface that is assigned to the virtual
router you specified.

Firepower Management Center Configuration Guide, Version 6.3

1333
 7000 and 8000 Series Advanced Deployment Options
Star VPN Deployment Options

IP Address
• If you chose a managed device as an endpoint, choose an IP address that is assigned to the specified
routed interface.
• If the managed device is a device high-availability pair, you can choose only from a list of SFRP
IP addresses.
• If you choose a managed device not managed by the Firepower Management Center, specify an IP
address for the endpoint.

Protected Networks
Specify the networks in your deployment that are encrypted. Enter a subnet with CIDR block for each
network. IKE version 1 only supports a single protected network.
Note that VPN endpoints cannot have the same IP address and that 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
entry, the other endpoint's protected network must have at least one entry of the same type (i.e., 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.
Internal IP
Check the check box if the endpoint resides behind a firewall with network address translation.
Public IP
If you checked the Internal IP check box, specify a public IP address for the firewall. If the endpoint is
a responder, you must specify this value.
Public IKE Port
If you checked the Internal IP check box, specify a single numerical value from 1 to 65535 for the UDP
port on the firewall that is being port-forwarded to the internal endpoint. If the endpoint is a responder
and the port on the firewall being forwarded is not 500 or 4500, you must specify this value.
Use Deployment Key
Check the check box to use the pre-shared key defined for the deployment. Clear the check box to specify
a pre-shared key for VPN authentication for this endpoint pair.
Pre-shared Key
If you cleared the Use Deployment Key check box, specify a pre-shared key in this field.
Related Topics
Configuring Point-to-Point VPN Deployments, on page 1339

Star VPN Deployment Options

When configuring a star VPN deployment, you define a single hub node endpoint and a group of leaf node
endpoints. You must define the hub node endpoint and at least one leaf node endpoint to configure the
deployment.
The following list describes the options you can specify in your deployment.
Name
Specify a unique name for the deployment.

Firepower Management Center Configuration Guide, Version 6.3

1334
7000 and 8000 Series Advanced Deployment Options
Star VPN Deployment Options

Type
Click Star to specify that you are configuring a star deployment.
Pre-shared Key
Define a unique pre-shared key for authentication.
Device
You can choose a managed device, including a device stack or device high-availability pair, as an endpoint
for your deployment. For Cisco-managed devices not managed by the Firepower Management Center
you are using, choose Other and then specify an IP address for the endpoint.
Virtual Router
If you chose a managed device as your endpoint, choose a virtual router that is currently applied to the
selected device. You cannot choose the same virtual router for more than one endpoint.
Interface
If you chose a managed device as your endpoint, choose a routed interface that is assigned to the selected
virtual router.
IP Address
• If you chose a managed device as an endpoint, choose an IP address that is assigned to the specified
routed interface.
• If the managed device is a device high-availability pair, you can choose only from a list of SFRP
IP addresses.
• If you chose a managed device not managed by the Firepower Management Center, specify an IP
address for the endpoint.

Protected Networks
Specify the networks in your deployment that are encrypted. Enter a subnet with CIDR block for each
network.
Note that VPN endpoints cannot have the same IP address and that 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
entry, the other endpoint's protected network must have at least one entry of the same type (i.e., 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.
Internal IP
Check the check box if the endpoint resides behind a firewall with network address translation.
Public IP
If you checked the Internal IP check box, specify a public IP address for the firewall. If the endpoint is
a responder, you must specify this value.
Public IKE Port
If you checked the Internal IP check box, specify a single numerical value from 1 to 65535 for the UDP
port on the firewall that is being port-forwarded to the internal endpoint. If the endpoint is a responder
and the port on the firewall being forwarded is not 500 or 4500, you must specify this value.

Firepower Management Center Configuration Guide, Version 6.3

1335
 7000 and 8000 Series Advanced Deployment Options
Mesh VPN Deployment Options

Related Topics
Configuring Star VPN Deployments, on page 1339

Mesh VPN Deployment Options

When configuring a mesh VPN deployment, you define a group of VPNs to link any two points for a given
set of endpoints.
The following list describes the options you can specify in your deployment.
Name
Specify a unique name for the deployment.
Type
Click Mesh to specify that you are configuring a mesh deployment.
Pre-shared Key
Define a unique pre-shared key for authentication.
Device
You can choose a managed device, including a device stack or device high-availability pair, as an endpoint
for your deployment. For Cisco-managed devices not managed by the Firepower Management Center
you are using, choose Other and then specify an IP address for the endpoint.
Virtual Router
If you chose a managed device as your endpoint, choose a virtual router that is currently applied to the
specified device. You cannot choose the same virtual router for more than one endpoint.
Interface
If you chose a managed device as your endpoint, choose a routed interface that is assigned to the specified
virtual router.
IP Address
• If you chose a managed device as an endpoint, choose an IP address that is assigned to the selected
routed interface.
• If the managed device is a device high-availability pair, you can choose only from a list of SFRP
IP addresses.
• If you chose a managed device not managed by the Firepower Management Center, specify an IP
address for the endpoint.

Protected Networks
Specify the networks in your deployment that are encrypted. Enter a subnet with CIDR block for each
network. IKE version 1 only supports a single protected network.
Note that VPN endpoints cannot have the same IP address and that 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
entry, the other endpoint's protected network must have at least one entry of the same type (i.e., 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.

Firepower Management Center Configuration Guide, Version 6.3

1336
 7000 and 8000 Series Advanced Deployment Options
Advanced VPN Deployment Options

Internal IP
Check the check box if the endpoint resides behind a firewall with network address translation.
Public IP
If you checked the Internal IP check box, specify a public IP address for the firewall. If the endpoint is
a responder, you must specify this value.
Public IKE Port
If you checked the Internal IP check box, specify a single numerical value from 1 to 65535 for the UDP
port on the firewall that is being port-forwarded to the internal endpoint. If the endpoint is a responder
and the port on the firewall being forwarded is not 500 or 4500, you must specify this value.
Related Topics
Configuring Mesh VPN Deployments, on page 1340

Advanced VPN Deployment Options

VPN deployments contain some common settings that can be shared among the VPNs in a deployment. Each
VPN can use the default settings or you can override the default settings. Advanced settings typically require
little or no modification and are not common to every deployment.
The following list describes the advanced options you can specify in your deployment.
Other Algorithm Allowed
Check the check box to enable auto negotiation to an algorithm not listed in the Algorithm list, but
proposed by the remote peer.
Algorithm
Specify the phase one and phase two algorithm proposals to secure data in your deployment. Choose
Cipher, Hash, and Diffie-Hellman (DH) group authentication messages for both phases.
IKE Life Time
Specify a numerical value and choose a time unit for the maximum IKE SA renegotiation interval. You
can specify a minimum of 15 minutes and a maximum of 30 days.
IKE v2
Check the check box to specify that the system uses IKE version 2. This version supports the star
deployment and multiple protected networks.
Life Time
Specify a numerical value and select a time unit for the maximum SA renegotiation interval. You can
specify a minimum of 5 minutes and a maximum of 24 hours.
Life Packets
Specify the number of packets that can be transmitted over an IPsec SA before it expires. You can use
any integer between 0 and 18446744073709551615.
Life Bytes
Specify the number of bytes that can be transmitted over an IPsec SA before it expires. You can use any
integer between 0 and 18446744073709551615.

Firepower Management Center Configuration Guide, Version 6.3

1337
 7000 and 8000 Series Advanced Deployment Options
Managing VPN Deployments

AH
Check the check box to specify that the system uses the authentication header security protocol for the
data to be protected. Clear the check box to use encryption service payload (ESP) protocol.
Related Topics
Configuring Advanced VPN Deployment Settings, on page 1341

Managing VPN Deployments

Smart License Classic License Supported Devices Supported Domains Access

N/A VPN 7000 & 8000 Series Any Admin/Network

Admin

Caution Adding or removing a VPN on a 7000 or 8000 Series device 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 312 for more information.

Procedure

Step 1 Choose Devices > VPN > Site to Site.

Step 2 Manage your VPN deployments:
• Add — To create a new VPN deployment, click Add VPN > Firepower Device, and continue as follows
depending on deployment type:
• Configuring Mesh VPN Deployments, on page 1340
• Configuring Point-to-Point VPN Deployments, on page 1339
• Configuring Star VPN Deployments, on page 1339

• Edit — To modify the settings in an existing VPN deployment, click the edit icon ( ); see Editing VPN
Deployments, on page 1342.

• Delete — To delete a VPN deployment, click the delete icon ( ).

• Deploy—Click Deploy; see Deploy Configuration Changes, on page 308.
• View VPN status — To view the status of an existing VPN deployment, click the status icon; see Viewing
VPN Status, on page 1343.

Related Topics
Snort® Restart Scenarios, on page 311

Firepower Management Center Configuration Guide, Version 6.3

1338
 7000 and 8000 Series Advanced Deployment Options
Configuring Point-to-Point VPN Deployments

Configuring Point-to-Point VPN Deployments

Smart License Classic License Supported Devices Supported Domains Access

N/A VPN 7000 & 8000 Series Any Admin/Network

Admin

Before you begin

If you are using managed devices as endpoints, create a virtual router and apply it to the appropriate device.

Note You cannot use the same virtual router for more than one endpoint. For more information, see Setting Up
Virtual Routers, on page 1279

Procedure

Step 1 Choose Devices > VPN > Site to Site.

Step 2 Click Add VPN > Firepower Device.
Step 3 Enter a unique Name.
Step 4 Verify that PTP is chosen as the Type.
Step 5 Enter a unique Pre-shared Key.

Step 6 Next to Node Pairs, click the add icon ( ).

Step 7 Configure the VPN deployment options described in Point-to-Point VPN Deployment Options, on page 1333.

Step 8 Under Node A, next to Protected Networks, click the add icon ( ).
Step 9 Enter a CIDR block for the protected network.
Step 10 Click OK.
Step 11 Repeat step 8 through step 10 for Node B.
Step 12 Click Save.
The endpoint pair is added to your deployment.
Step 13 Click Save to finish configuring your deployment.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring Star VPN Deployments

Smart License Classic License Supported Devices Supported Domains Access

N/A VPN 7000 & 8000 Series Any Admin/Network

Admin

Firepower Management Center Configuration Guide, Version 6.3

1339
 7000 and 8000 Series Advanced Deployment Options
Configuring Mesh VPN Deployments

Before you begin

If you are using managed devices as endpoints, create a virtual router and apply it to the appropriate device.

Note You cannot use the same virtual router for more than one endpoint. For more information, see Setting Up
Virtual Routers, on page 1279

Procedure

Step 1 Choose Devices > VPN > Site to Site.

Step 2 Click Add VPN > Firepower Device.
Step 3 Enter a unique Name.
Step 4 Click Star to specify the Type.
Step 5 Enter a unique Pre-shared Key.

Step 6 Next to Hub Node, click the edit icon ( ).

Step 7 Configure the VPN deployment options described in Star VPN Deployment Options, on page 1334.

Step 8 Next to Protected Networks, click the add icon ( ).

Step 9 Enter an IP address for the protected network.
Step 10 Click OK.
Step 11 Click Save. The hub node is added to your deployment.

Step 12 Next to Leaf Nodes, click the add icon ( ).

Step 13 Repeat step 7 through step 10 to complete the leaf node, which has the same options as the hub node.
Step 14 Click Save.
The leaf node is added to your deployment.
Step 15 Click Save to finish configuring your deployment.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring Mesh VPN Deployments

Smart License Classic License Supported Devices Supported Domains Access

N/A VPN 7000 & 8000 Series Any Admin/Network

Admin

Before you begin

If you are using managed devices as endpoints, create a virtual router and apply it to the appropriate device.

Firepower Management Center Configuration Guide, Version 6.3

1340
 7000 and 8000 Series Advanced Deployment Options
Configuring Advanced VPN Deployment Settings

Note You cannot use the same virtual router for more than one endpoint. For more information, see Setting Up
Virtual Routers, on page 1279

Procedure

Step 1 Choose Devices > VPN > Site to Site.

Step 2 Click Add VPN > Firepower Device.
Step 3 Enter a unique Name.
Step 4 Click Mesh to specify the Type.
Step 5 Enter a unique Pre-shared Key.

Step 6 Next to Nodes, click the add icon ( ).

Step 7 Configure the VPN deployment options described in Mesh VPN Deployment Options, on page 1336.

Step 8 Next to Protected Networks, click the add icon ( ).

Step 9 Enter a CIDR block for the protected network.
Step 10 Click OK.
The protected network is added.
Step 11 Click Save.
The endpoint is added to your deployment.
Step 12 Repeat step 6 through step 11 to add more endpoints.
Step 13 Click Save to complete your deployment.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring Advanced VPN Deployment Settings

Smart License Classic License Supported Devices Supported Domains Access

N/A VPN 7000 & 8000 Series Any Admin/Network

Admin

In a multidomain deployment, the system displays VPN deployments created in the current domain, which
you can edit. It also displays VPN deployments created in ancestor domains if one of the endpoint devices
belongs to your domain. You cannot edit VPN deployments created in ancestor domains. To view and edit
VPN deployments created in a lower domain, switch to that domain.

Procedure

Step 1 Choose Devices > VPN > Site to Site.

Firepower Management Center Configuration Guide, Version 6.3

1341
 7000 and 8000 Series Advanced Deployment Options
Editing VPN Deployments

Step 2 Click the edit icon ( ).

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

Step 3 Click the Advanced tab.

Step 4 Configure the advanced settings, as described in Advanced VPN Deployment Options, on page 1337.

Step 5 Next to Algorithms, click the add icon ( ).

Step 6 Chose Cipher, Hash, and Diffie-Hellman (DH) group authentication messages for both phases.
Step 7 Click OK.
Step 8 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Editing VPN Deployments

Caution Two users should not edit the same deployment simultaneously; however, note that the web interface does
not prevent simultaneous editing.

In a multidomain deployment, the system displays VPN deployments created in the current domain, which
you can edit. It also displays VPN deployments created in ancestor domains if one of the endpoint devices
belongs to your domain. You cannot edit VPN deployments created in ancestor domains. To view and edit
VPN deployments created in a lower domain, switch to that domain.

Procedure

Step 1 Choose Devices > VPN > Site to Site.

Step 2 Click the edit icon ( ).

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

Step 3 Modify the desired settings:

• Advanced settings; see Configuring Advanced VPN Deployment Settings, on page 1341.
• Mesh deployment settings; see Configuring Mesh VPN Deployments, on page 1340.
• Point-to-point deployment settings; see Configuring Point-to-Point VPN Deployments, on page 1339.
• Star deployment settings; see Configuring Star VPN Deployments, on page 1339.

Firepower Management Center Configuration Guide, Version 6.3

1342
 7000 and 8000 Series Advanced Deployment Options
VPN Deployment Status

Tip You cannot edit the deployment type after you initially save the deployment. To change the
deployment type, you must delete the deployment and create a new one.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

VPN Deployment Status

After you configure a VPN deployment, you can view the status of your configured VPN tunnels. The VPN
page displays a status icon for each VPN deployment once it has been deployed:

• The ( ) icon designates that all VPN endpoints are up.

• The ( ) icon designates that all VPN endpoints are down.

• The ( ) icon designates that some endpoints are up, while others are down.

You can click a status icon to view the deployment status along with basic information about the endpoints
in the deployment, such as endpoint name and IP address. The VPN status updates every minute or when a
status change occurs, such as an endpoint going down or coming up.
Related Topics
Viewing VPN Status, on page 1343

Viewing VPN Status

Smart License Classic License Supported Devices Supported Domains Access

N/A VPN 7000 & 8000 Series Any Admin/Network

Admin

In a multidomain deployment, the system displays VPN deployments created in the current domain. It also
displays VPN deployments created in ancestor domains if one of the endpoint devices belongs to your domain.
To view VPN deployments created in a lower domain, switch to that domain.

Procedure

Step 1 Choose Devices > VPN > Site to Site.

Step 2 Click the VPN status icon next to the deployment where you want to view the status.
Step 3 Click OK.

Firepower Management Center Configuration Guide, Version 6.3

1343
 7000 and 8000 Series Advanced Deployment Options
VPN Statistics and Logs

VPN Statistics and Logs

After you configure a VPN deployment, you can view statistics about the data traversing your configured
VPN tunnels. In addition, you can view the latest VPN system and IKE logs for each endpoint.
The system displays the following statistics:
Endpoint
The device path to the routed interface and IP address designated as the VPN endpoint.
Status
Whether the VPN connection is up or down.
Protocol
The protocol used for encryption, either ESP or AH.
Packets Received
The number of packets per interface the VPN tunnel receives during an IPsec SA negotiation.
Packets Forwarded
The number of packets per interface the VPN tunnel transmits during an IPsec SA negotiation.
Bytes Received
The number of bytes per interface the VPN tunnel receives during an IPsec SA negotiation.
Bytes Forwarded
The number of bytes per interface the VPN tunnel transmits during an IPsec SA negotiation.
Time Created
The date and time the VPN connection was created.
Time Last Used
The last time a user initiated a VPN connection.
NAT Traversal
If "Yes" is displayed, at least one of the VPN endpoints resides behind a device with network address
translation.
IKE State
The state of the IKE SA: connecting, established, deleting, or destroying.
IKE Event
The IKE SA event: reauthentication or rekeying.
IKE Event Time
The time in seconds the next event should occur.
IKE Algorithm
The IKE algorithm being used by the VPN deployment.

Firepower Management Center Configuration Guide, Version 6.3

1344
 7000 and 8000 Series Advanced Deployment Options
Viewing VPN Statistics and Logs

IPsec State
The state of the IPsec SA: installing, installed, updating, rekeying, deleting, and destroying.
IPsec Event
Notification of when the IPsec SA event is rekeying.
IPsec Event Time
The time in seconds until the next event should occur.
IPsec Algorithm
IPsec algorithm being used by the VPN deployment.
Related Topics
Viewing VPN Statistics and Logs, on page 1345

Viewing VPN Statistics and Logs

Smart License Classic License Supported Devices Supported Domains Access

N/A VPN 7000 & 8000 Series Any Admin/Network

Admin

In a multidomain deployment, the system displays VPN deployments created in the current domain. It also
displays VPN deployments created in ancestor domains if one of the endpoint devices belongs to your domain.
To view VPN deployments created in a lower domain, switch to that domain.

Procedure

Step 1 Choose Devices > VPN > Site to Site.

Step 2 Click the VPN status icon next to the deployment for which you want to view statistics.

Step 3 Click the view statistics icon ( ).

Step 4 Optionally, click Refresh to update the VPN statistics.
Step 5 Optionally, click View Recent Log to view the latest data log for each endpoint. To view the log for 7000 or
8000 Series devices in high-availability pairs and stacked devices, you can click the link for either the
active/primary or backup/secondary device.

Firepower Management Center Configuration Guide, Version 6.3

1345
 7000 and 8000 Series Advanced Deployment Options
Viewing VPN Statistics and Logs

Firepower Management Center Configuration Guide, Version 6.3

1346
PA R T XVII
Access Control
• Getting Started with Access Control Policies, on page 1349
• Access Control Rules, on page 1367
• Access Control Using Intrusion and File Policies, on page 1381
• URL Filtering, on page 1389
• HTTP Response Pages and Interactive Blocking, on page 1401
• Security Intelligence Blacklisting, on page 1405
• DNS Policies, on page 1411
• Prefiltering and Prefilter Policies, on page 1423
• Intelligent Application Bypass, on page 1435
• Access Control Using Content Restriction, on page 1443
 CHAPTER 62
Getting Started with Access Control Policies
The following topics describe how to start using access control policies:
• Introduction to Access Control, on page 1349
• Managing Access Control Policies, on page 1354
• Creating a Basic Access Control Policy, on page 1355
• Editing an Access Control Policy, on page 1356
• Managing Access Control Policy Inheritance, on page 1358
• Setting Target Devices for an Access Control Policy, on page 1361
• Logging Settings, on page 1362
• Access Control Policy Advanced Settings, on page 1362

Introduction to Access Control

Access control is a hierarchical policy-based feature that allows you to specify, inspect, and log
(non-fast-pathed) network traffic. Especially useful in multidomain deployments, you can nest access control
policies, where each policy inherits the rules and settings from an ancestor (or base) policy. You can enforce
this inheritance, or allow lower-level policies to override their ancestors. Each managed device can be targeted
by one access control policy.
The data that the policy’s target devices collect about your network traffic can be used to filter and control
that traffic based on:
• simple, easily determined transport and network layer characteristics: source and destination, port,
protocol, and so on
• the latest contextual information on the traffic, including characteristics such as reputation, risk, business
relevance, application used, or URL visited
• realm, user, user group, or ISE attribute
• custom Security Group Tag (SGT)
• characteristics of encrypted traffic; you can also decrypt this traffic for further analysis
• whether unencrypted or decrypted traffic contains a prohibited file, detected malware, or intrusion attempt

Each type of traffic inspection and control occurs where it makes the most sense for maximum flexibility and
performance. For example, reputation-based blacklisting uses simple source and destination data, so it can

Firepower Management Center Configuration Guide, Version 6.3

1349
 Access Control
Access Control Policy Components

block prohibited traffic early in the process. In contrast, detecting and blocking intrusions and exploits is a
last-line defense.
Although you can configure the system without licensing your deployment, many features require that you
enable the appropriate licenses before you deploy. Also, some features are only available on certain device
models. Warning icons and confirmation dialog boxes designate unsupported features.

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. Sometimes, the system prevents you from deploying
inline configurations to passively deployed devices, including inline devices in tap mode. In other cases, the
policy may deploy successfully, but attempting to block or alter traffic using passively deployed devices can
have unexpected results. For example, the system may report multiple beginning-of-connection events for
each blocked connection, because blocked connections are not blocked in passive deployments.

Access Control Policy Components

A newly created access control policy directs its target devices to handle all traffic using its default action.
The following list describes the configurations you can change after you create a simple policy.

Note You can only edit access control policies that were created in the current domain. Also, you cannot edit settings
that are locked by an ancestor access control policy.

Name and Description

Each access control policy must have a unique name. A description is optional.
Inheritance Settings
Policy inheritance allows you to create a hierarchy of access control policies. A parent (or base) policy
defines and enforces default settings for its descendants, which is especially useful in multidomain
deployments.
A policy's inheritance settings allow you to select its base policy. You can also lock settings in the current
policy to force any descendants to inherit them. Descendant policies can override unlocked settings.
Policy Assignment
Each access control policy identifies the devices that use it. Each device can be targeted by only one
access control policy. In a multidomain deployment, you can require that all the devices in a domain use
the same base policy.
Rules
Access control rules provide a granular method of handling network traffic. Rules in an access control
policy are numbered, starting at 1, including rules inherited from ancestor policies. The system matches
traffic to access control rules in top-down order by ascending rule number.
Usually, the system handles network traffic according to the first access control rule where all the rule’s
conditions match the traffic. Conditions can be simple or complex, and their use often depends on certain
licenses.

Firepower Management Center Configuration Guide, Version 6.3

1350
 Access Control
Access Control Policy Default Action

Default Action
The default action determines how the system handles and logs traffic that is not handled by any other
access control configuration. The default action can block or trust all traffic without further inspection,
or inspect traffic for intrusions and discovery data.
Although an access control policy can inherit its default action from an ancestor policy, you cannot
enforce this inheritance.
Security Intelligence
Security Intelligence is a first line of defense against malicious internet content. This feature allows you
to blacklist (block) connections based on the latest IP address, URL, and domain name reputation
intelligence. To ensure continual access to vital resources, you can override blacklists with custom
whitelists.
HTTP Responses
When the system blocks a user’s website request, you can either display a generic system-provided
response page, or a custom page. You can also display a page that warns users, but also allows them to
continue to the originally requested site.
Logging
Settings for access control policy logging allow you to configure default syslog destinations for the
current access control policy. The settings are applicable to the access control policy and all the included
SSL, prefilter, and intrusion policies unless the syslog destination settings are explicitly overridden with
custom settings in included rules and policies.
Advanced Access Control Options
Advanced access control policy settings typically require little or no modification. Often, the default
settings are appropriate. Advanced settings you can modify include traffic preprocessing, SSL inspection,
identity, and various performance options.
Related Topics
Rule Management: Common Characteristics, on page 321

Access Control Policy Default Action

In a simple access control policy, the default action specifies how target devices handle all traffic. In a more
complex policy, the default action handles traffic that:
• is not trusted by Intelligent Application Bypass
• is not blacklisted by Security Intelligence
• is not blocked by SSL inspection (encrypted traffic only)
• matches none of the rules in the policy (except Monitor rules, which match and log—but do not handle
or inspect—traffic)

The access control policy default action can block or trust traffic without further inspection, or inspect traffic
for intrusions and discovery data.

Firepower Management Center Configuration Guide, Version 6.3

1351
 Access Control
Access Control Policy Default Action

Note You cannot perform file or malware inspection on traffic handled by the default action. Logging for connections
handled by the default action is initially disabled, though you can enable it.

If you are using policy inheritance, the default action for the lowest-level descendant determines final traffic
handling. Although an access control policy can inherit its default action from its base policy, you cannot
enforce this inheritance.
The following table describes the types of inspection you can perform on traffic handled by each default
action.

Table 91: Access Control Policy Default Actions

Default Action Effect on Traffic Inspection Type and Policy

Access Control: Block All Traffic block without further inspection none

Access Control: Trust All Traffic trust (allow to its final destination none
without further inspection)

Intrusion Prevention allow, as long as it is passed by the intrusion, using the specified
intrusion policy you specify intrusion policy and associated
variable set, and
discovery, using the network
discovery policy

Network Discovery Only allow discovery only, using the network

discovery policy

Inherit from base policy defined in base policy defined in base policy

The following diagram illustrates the table.

The following diagrams illustrate the Block All Traffic and Trust All Traffic default actions.

Firepower Management Center Configuration Guide, Version 6.3

1352
 Access Control
Access Control Policy Inheritance

The following diagrams illustrate the Intrusion Prevention and Network Discovery Only default actions.

Tip The purpose of Network Discovery Only is to improve performance in a discovery-only deployment. Different
configurations can disable discovery if you are only interested in intrusion detection and prevention.

Related Topics
Performance Considerations for Limited Deployments, on page 319
Logging Connections with a Policy Default Action, on page 2457

Access Control Policy Inheritance

Access control uses a hierarchical policy-based implementation that complements multitenancy. Just as you
create a domain hierarchy, you can create a corresponding hierarchy of access control policies. A descendant,
or child, access control policy inherits rules and settings from its direct parent, or base, policy. That base
policy may have its own parent policy from which it inherits rules and settings, and so on.
An access control policy’s rules are nested between its parent policy’s Mandatory and Default rule sections.
This implementation enforces Mandatory rules from ancestor policies, but allows the current policy to write
rules that preempt Default rules from ancestor policies.
You can lock the following settings to enforce them in all descendant policies. Descendant policies can override
unlocked settings.
• Security Intelligence — Blacklisting and whitelisting connections based on the latest IP address, URL,
and domain name reputation intelligence.

Firepower Management Center Configuration Guide, Version 6.3

1353
 Access Control
Managing Access Control Policies

• HTTP Response pages — Displaying a custom or system-provided response page when you block a
user's website request.
• Advanced settings — Specifying associated subpolicies, network analysis settings, performance settings,
and other general options.

Although an access control policy can inherit its default action from an ancestor policy, you cannot enforce
this inheritance.

Policy Inheritance and Multitenancy

In a typical multidomain deployment, access control policy hierarchy corresponds to domain structure, and
you apply the lowest-level access control policy to managed devices. This implementation allows selective
access control enforcement at a higher domain level, while lower-level domain administrators can tailor
deployment-specific settings. (You must use roles, not policy inheritance and enforcement alone, to restrict
administrators in descendant domains.)
For example, as a Global domain administrator for your organization, you can create an access control policy
at the Global level. You can then require that all your devices, which are divided into subdomain by function,
use that Global-level policy as a base policy.
When subdomain administrators log into the Firepower Management Center to configure access control, they
can deploy the Global-level policy as-is. Or, they can create and deploy a descendant access control policy
within the boundaries of the Global-level policy.

Note Although the most useful implementation of access control inheritance and enforcement complements
multitenancy, you can create a hierarchy of access control policies within a single domain. You can also assign
and deploy access control policies at any level.

Related Topics
Managing Access Control Policy Inheritance, on page 1358
Security Intelligence Blacklisting, on page 1405
HTTP Response Pages and Interactive Blocking, on page 1401
Access Control Policy Advanced Settings, on page 1362
Logging Settings, on page 1362

Managing Access Control Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin

Access Admin
Network Admin

The Firepower System allows you to edit system-provided access control policies and create custom access
control policies. Depending on your devices' initial configurations, system-provided policies can include:
• Default Access Control—Blocks all traffic without further inspection.

Firepower Management Center Configuration Guide, Version 6.3

1354
 Access Control
Creating a Basic Access Control Policy

• Default Intrusion Prevention—Allows all traffic, but also inspects with the Balanced Security and
Connectivity intrusion policy and default intrusion variable set.
• Default Network Discovery—Allows all traffic while inspecting it for discovery data but not intrusions
or exploits.

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.

Procedure

Step 1 Choose Policies > Access Control .

Step 2 Manage access control policies:

• Copy—Click the copy icon ( )..

• Create—Click New Policy; see Creating a Basic Access Control Policy, on page 1355.

• Delete—Click the delete icon ( ).

• Deploy—Click Deploy; see Deploy Configuration Changes, on page 308.

• Edit—Click the edit icon ( ); see Editing an Access Control Policy, on page 1356

• Inheritance—Click the plus icon ( ) next to a policy with desdendants to expand your view of the
policy's hierarchy.
• Import/Export—Click Import/Export; see Configuration Import and Export, on page 187.

• Report—Click the report icon ( ); see Generating Current Policy Reports, on page 317.

Related Topics
Out-of-Date Policies, on page 318

Creating a Basic Access Control Policy

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

When you create a new access control policy, you must, at minimum, choose a default action.
In most cases, logging of connections handled by a default action is initially disabled. An exception occurs
if you create a subpolicy in a multidomain deployment. In that case, the system enables connection logging
according to the logging configuration of the inherited default action.

Firepower Management Center Configuration Guide, Version 6.3

1355
 Access Control
Editing an Access Control Policy

Procedure

Step 1 Choose Policies > Access Control .

Step 2 Click New Policy.
Step 3 Enter a unique Name and, optionally, a Description.
Step 4 Optionally, choose a base policy from the Select Base Policy drop-down list.
If an access control policy is enforced on your domain, this step is not optional. You must choose the enforced
policy or one of its descendants as the base policy.

Step 5 Specify the initial Default Action:

• If you chose a base policy, your new policy inherits its default action. You cannot change it here.
• Block all traffic creates a policy with the Access Control: Block All Traffic default action.
• Intrusion Prevention creates a policy with the Intrusion Prevention: Balanced Security and
Connectivity default action, associated with the default intrusion variable set.
• Network Discovery creates a policy with the Network Discovery Only default action.
Tip If you want to trust all traffic by default, or if you chose a base policy and do not want to inherit
the default action, you can change the default action later.

Step 6 Optionally, choose the Available Devices where you want to deploy the policy, then click Add to Policy (or
drag and drop) to add the selected devices. To narrow the devices that appear, type a search string in the
Search field.
If you want to deploy this policy immediately, you must perform this step.

Step 7 Click Save.

What to do next
• Optionally, further configure the new policy as described in Editing an Access Control Policy, on page
1356.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Access Control Policy Default Action, on page 1351
Setting Target Devices for an Access Control Policy, on page 1361

Editing an Access Control Policy

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network Admin

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

Firepower Management Center Configuration Guide, Version 6.3

1356
Access Control
Editing an Access Control Policy

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.

Procedure

Step 1 Choose Policies > Access Control .

Step 2 Click the edit icon ( ) next to the access control policy you want to edit.

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

Step 3 Edit your access control policy:

• Name and Description—Click either field and enter new information.
• Default Action—Choose a value from the Default Action drop-down list.

• Default Action Variable Set—To change the variable set associated with an Intrusion Prevention default
action, click the variables icon ( ). In the popup window that appears, select a new variable set and
click OK. You can also click the edit icon ( ) to edit the selected variable set in a new window. For
more information, see Managing Variables, on page 394.
• Default Action Logging—To configure logging for connections handled by the default action, click the
logging icon ( ); see Logging Connections with a Policy Default Action, on page 2457.
• HTTP Responses—To specify what the user sees in a browser when the system blocks a website request,
click the HTTP Responses tab; see Choosing HTTP Response Pages, on page 1402.
• Inheritance: Change Base Policy—To change the base access control policy for this policy, click
Inheritance Settings; see Choosing a Base Access Control Policy, on page 1359.
• Inheritance: Lock Settings in Descendants—To enforce this policy's settings in its descendant policies,
click Inheritance Settings; see Locking Settings in Descendant Access Control Policies, on page 1360.
• Policy Assignment: Targets—To identify the managed devices targeted by this policy, click Policy
Assignment; see Setting Target Devices for an Access Control Policy, on page 1361.
• Policy Assignment: Required in Domains—To enforce this policy in a subdomain, click Policy
Assignment; see Requiring an Access Control Policy in a Domain, on page 1360.
• Rules—To manage access control rules, and to inspect and block malicious traffic using intrusion and
file policies, click the Rules tab; see Creating and Editing Access Control Rules, on page 1374.
• Rule Conflicts—To show rule conflict warnings, enable Show rule conflicts. Rule conflicts occur when
a rule will never match traffic because an earlier rule always matches the traffic first. Because determining
rule conflicts is resource intensive, displaying them may take some time. For more information, see
Guidelines for Ordering Rules, on page 353.
• Security Intelligence—To immediately blacklist (block) connections based on the latest reputation
intelligence, click the Security Intelligence tab; see Configure Security Intelligence, on page 1407.
• Advanced Options—To set preprocessing, SSL inspection, identity, performance, and other advanced
options, click the Advanced tab; see Access Control Policy Advanced Settings, on page 1362.

Firepower Management Center Configuration Guide, Version 6.3

1357
 Access Control
Managing Access Control Policy Inheritance

• Warnings—To view a list of warnings or errors in your access control policy (and its descendant and
associated policies), click Show Warnings. Warnings and errors mark configurations that could adversely
affect traffic analysis and flow or prevent the policy from deploying. If there are no warnings, the button
does not appear. To view rule conflict warnings, first enable Show rule conflicts.

Step 4 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Rule and Other Policy Warnings, on page 351
About Deep Inspection, on page 1381

Managing Access Control Policy Inheritance

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network Admin

Procedure

Step 1 Edit the access control policy whose inheritance settings you want to change; see Editing an Access Control
Policy, on page 1356.
Step 2 Manage policy inheritance:
• Change Base Policy — To change the base access control policy for this policy, click Inheritance
Settings and proceed as described in Choosing a Base Access Control Policy, on page 1359.
• Lock Settings in Descendants — To enforce this policy's settings in its descendant policies, click
Inheritance Settings and proceed as described in Locking Settings in Descendant Access Control Policies,
on page 1360 .
• Required in Domains — To enforce this policy in a subdomain, click Policy Assignment and proceed
as described in Requiring an Access Control Policy in a Domain, on page 1360.
• Inherit Settings from Base Policy — To inherit settings from a base access control policy, click the
Security Intelligence, HTTP Responses, or Advanced tab and proceed as directed in Inheriting Access
Control Policy Settings from the Base Policy, on page 1359.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1358
 Access Control
Choosing a Base Access Control Policy

Choosing a Base Access Control Policy

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network Admin

You can use one access control policy as the base (parent) for another. By default, a child policy inherits its
settings from its base policy, though you can change unlocked settings.
When you change the base policy for the current access control policy, the system updates the current policy
with any locked settings from the new base policy.

Procedure

Step 1 In the access control policy editor, click Inheritance Settings.

Step 2 Choose a policy from the Select Base Policy drop-down list.
In a multidomain deployment, an access control policy may be required in the current domain. You can choose
only the enforced policy or one of its descendants as the base policy.

Step 3 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Inheriting Access Control Policy Settings from the Base Policy

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network Admin

A new child policy inherits many settings from its base policy. If these settings are unlocked in the base policy,
you can override them.
If you later reinherit the settings from the base policy, the system displays the base policy's settings and dims
the controls. However, the system saves the overrides you made, and restores them if you disable inheritance
again.

Procedure

Step 1 In the access control policy editor, click the Security Intelligence, HTTP Responses, or Advanced tab.
Step 2 Check the Inherit from base policy check box for each setting you want to inherit.
If the controls are dimmed, settings are inherited from an ancestor policy, or you do not have permission to
modify the configuration.

Firepower Management Center Configuration Guide, Version 6.3

1359
 Access Control
Locking Settings in Descendant Access Control Policies

Step 3 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Locking Settings in Descendant Access Control Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network Admin

Lock a setting in an access control policy to enforce the setting in all descendant policies. Descendant policies
can override unlocked settings.
When you lock settings, the system saves overrides already made in descendant polices so that the overrides
can be restored if you unlock settings again.

Procedure

Step 1 In the access control policy editor, click Inheritance Settings.

Step 2 In the Child Policy Inheritance Settings area, check the settings you want to lock.
If the controls are dimmed, settings are inherited from an ancestor policy, or you do not have permission to
modify the configuration.

Step 3 Click OK to save the inheritance settings.

Step 4 Click Save to save the access control policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Requiring an Access Control Policy in a Domain

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network Admin

You can require that every device in a domain use the same base access control policy or one of its descendant
policies.

Firepower Management Center Configuration Guide, Version 6.3

1360
 Access Control
Setting Target Devices for an Access Control Policy

Before you begin

• Configure at least one domain other than the Global domain.

Procedure

Step 1 In the access control policy editor, click Policy Assignments.

Step 2 Click the Required on Domains tab.
Step 3 Build your domain list:
• Add — Select the domains where you want to enforce the current access control policy, then click Add
or drag and drop into the list of selected domains.
• Delete — Click the delete icon ( ) next to a leaf domain, or right-click an ancestor domain and choose
Delete Selected.
• Search — Type a search string in the search field. Click the clear icon ( ) to clear the search.

Step 4 Click OK to save the domain enforcement settings.

Step 5 Click Save to save the access control policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Setting Target Devices for an Access Control Policy

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

An access control policy specifies the devices that use it. Each device can be targeted by only one access
control policy. In multidomain deployments, you can require that all the devices in a domain use the same
base policy.

Procedure

Step 1 In the access control policy editor, click Policy Assignments.

Step 2 On the Targeted Devices tab, build your target list:
• Add — Select one or more Available Devices, then click Add to Policy or drag and drop into the list
of Selected Devices.
• Delete — Click the delete icon ( ) next to a single device, or select multiple devices, right-click, then
choose Delete Selected.

Firepower Management Center Configuration Guide, Version 6.3

1361
 Access Control
Logging Settings

• Search — Type a search string in the search field. Click the clear icon ( ) to clear the search.
Under Impacted Devices, the system lists the devices whose assigned access control policies are children of
the current policy. Any change to the current policy affects these devices.

Step 3 Optionally, click the Required on Domains tab to require that all the devices in the subdomains you choose
use the same base policy. See Requiring an Access Control Policy in a Domain, on page 1360.
Step 4 Click OK to save your targeted device settings.
Step 5 Click Save to save the access control policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Logging Settings
Settings for access control policy logging allow you to configure default syslog destinations and syslog alert
for the current access control policy. The settings are applicable to the access control policy and all the included
SSL, prefilter, and intrusion policies unless the syslog destination settings are explicitly overridden with
custom settings in included rules and policies.

Default Syslog Settings

Send using specific syslog alert: If you select this option, the events are sent based on the selected syslog
alert as configured using the instruction in Creating a Syslog Alert Response, on page 2287. You can select the
syslog alert from the list or add one by specifying the name, logging host, port, facility, and severity. For more
information, see Facilities and Severities for Intrusion Syslog Alerts, on page 2296. This option is applicable
to all devices.
FTD 6.3 and later: Use the syslog settings configured in the FTD Platform Settings policy deployed on
the device: If you select this option and select the severity, connection or intrusion events are sent with the
selected severity to syslog collectors configured in Platform Settings. Using this option, you can unify the
syslog configuration by configuring it in Platform Settings and reusing the settings in access control policy.
Severity selected in this section is applied to all connection and intrusion events. The default severity is
ALERT.
This option is applicable only to Firepower Threat Defense devices 6.3 and later.

Note Behavior of the options is altered when both the options are selected. The dynamic Summary section shows
the results of your selections.

Access Control Policy Advanced Settings

Advanced access control policy settings typically require little or no modification. The default settings are
appropriate for most deployments. Note that many of the advanced preprocessing and performance options

Firepower Management Center Configuration Guide, Version 6.3

1362
Access Control
Access Control Policy Advanced Settings

in access control policies may be modified by rule updates as described in Update Intrusion Rules, on page
150.

If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.

Caution See Configurations that Restart the Snort Process When Deployed or Activated, on page 313 for a list of
advanced setting modifications that restart the Snort process, temporarily interrupting traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on how the target
device handles traffic. See Snort® Restart Traffic Behavior, on page 312 for more information.

General Settings
To customize the number of characters you store for each URL requested by your users, see Limiting Logging
of Long URLs, on page 2458.
To customize the length of time before you re-block a website after a user bypasses an initial block, see Setting
the User Bypass Timeout for a Blocked Website, on page 1404.
Disable Retry URL cache miss lookup to allow the system to immediately pass traffic to a URL without a
cloud lookup when the category is not cached. The system treats URLs that require a cloud lookup as
Uncategorized until the cloud lookup completes with a different category. In passive deployments, the system
does not retry the lookup, as it cannot hold packets.
Disable Enable Threat Intelligence Director to stop publishing TID data to your configured devices. For
more information about TID, see Cisco Threat Intelligence Director (TID), on page 1589.
To inspect traffic when you deploy configuration changes unless specific configurations require restarting
the Snort process, ensure that Inspect traffic during policy apply is set to its default value (enabled). When
this option is enabled, resource demands could result in a small number of packets dropping without inspection.
Additionally, deploying some configurations restarts the Snort process, which interrupts traffic inspection.
Whether traffic drops during this interruption or passes without further inspection depends on how the target
device handles traffic. See Snort® Restart Scenarios, on page 311 for more information.

Associated Policies
Use advanced settings to associate subpolicies (SSL, identity, prefilter) with access control; see Associating
Other Policies with Access Control, on page 1365.

Network Analysis and Intrusion Policies

Advanced network analysis and intrusion policy settings allow you to:
• Change the access control policy’s default intrusion policy and associated variable set, which are used
to initially inspect traffic before the system can determine exactly how to inspect that traffic.
• Change the access control policy’s default network analysis policy, which governs many preprocessing
options.
• Use custom network analysis rules and network analysis policies to tailor preprocessing options to specific
security zones, networks, and VLANs.

Firepower Management Center Configuration Guide, Version 6.3

1363
 Access Control
Access Control Policy Advanced Settings

For more information, see Advanced Access Control Settings for Network Analysis and Intrusion Policies,
on page 1857.

Threat Defense Service Policy

You can use the Threat Defense Service Policy 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. This policy applies to Firepower Threat Defense devices
only, and will be ignored for any other device type. The service policy rules are applied after the access control
rules. For more information, see Threat Defense Service Policies, on page 935.

File and Malware Settings

File and Malware Inspection Performance and Storage Tuning, on page 1583 provides information on performance
options for file control and AMP for Networks.

Intelligent Application Bypass Settings

Intelligent Application Bypass (IAB) is an expert-level configuration that specifies applications to bypass or
test for bypass if traffic exceeds a combination of inspection performance and flow thresholds. For more
information, see Intelligent Application Bypass, on page 1435.

Transport/Network Layer Preprocessor Settings

Advanced transport and network preprocessor settings apply globally to all networks, zones, and VLANs
where you deploy your access control policy. You configure these advanced settings in an access control
policy rather than in a network analysis policy. For more information, see Advanced Transport/Network
Preprocessor Settings, on page 1947.

Detection Enhancement Settings

Advanced detection enhancement settings allow you to configure adaptive profiles so you can:
• Use file policies and applications in access control rules.
• Use service metadata in intrusion rules.
• In passive deployments, improve reassembly of packet fragments and TCP streams based on your
network’s host operating systems.

For more information, see Adaptive Profiles, on page 2001.

Performance Settings and Latency-Based Performance Settings

About Intrusion Prevention Performance Tuning, on page 1843 provides information on improving the
performance of your system as it analyzes traffic for attempted intrusions.
For information specific to latency-based performance settings, see Packet and Intrusion Rule Latency Threshold
Configuration, on page 1847.

Firepower Management Center Configuration Guide, Version 6.3

1364
 Access Control
Associating Other Policies with Access Control

Associating Other Policies with Access Control

Smart License Classic License Supported Devices Supported Domains Access

Any feature dependent feature dependent Any Admin/Access

Admin/Network
Admin

Use an access control policy's advanced settings to associate one of each of the following subpolicies with
the access control policy:
• SSL policy—Monitors, decrypts, blocks, or allows application layer protocol traffic encrypted with
Secure Socket Layer (SSL) or Transport Layer Security (TLS).

Caution Adding or removing an SSL policy restarts the Snort process when you deploy
configuration changes, temporarily interrupting traffic inspection. Whether traffic
drops during this interruption or passes without further inspection depends on
how the target device handles traffic. See Snort® Restart Traffic Behavior, on
page 312 for more information.

• Identity policy—Performs user authentication based on the realm and authentication method associated
with the traffic.
• Prefilter policy—Performs early traffic handling using limited network (layer 4) outer-header criteria.

Procedure

Step 1 In the access control policy editor, click the Advanced tab.

Step 2 Click the edit icon ( ) in the appropriate Policy Settings area.

If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.

Step 3 Choose a policy from the drop-down list.

If you choose a user-created policy, you can click the edit icon that appears to edit the policy.

Step 4 Click OK.

Step 5 Click Save to save the access control policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Snort® Restart Scenarios, on page 311

Firepower Management Center Configuration Guide, Version 6.3

1365
 Access Control
Associating Other Policies with Access Control

Firepower Management Center Configuration Guide, Version 6.3

1366
 CHAPTER 63
Access Control Rules
The following topics describe how to configure access control rules:
• Introduction to Access Control Rules, on page 1367
• Adding an Access Control Rule Category, on page 1373
• Creating and Editing Access Control Rules, on page 1374
• Enabling and Disabling Access Control Rules, on page 1375
• Positioning an Access Control Rule, on page 1376
• Access Control Rule Actions, on page 1376
• Access Control Rule Comments, on page 1379

Introduction to Access Control Rules

Within an access control policy, access control rules provide a granular method of handling network traffic
across multiple managed devices.

Note 8000 Series fastpathing, prefilter evaluation, Security Intelligence filtering, SSL inspection, user identification,
and some decoding and preprocessing occur before access control rules evaluate network traffic.

The system matches traffic to access control rules in the order you specify. In most cases, the system handles
network traffic according to the first access control rule where all the rule’s conditions match the traffic.
Each rule also has an action, which determines whether you monitor, trust, block, or allow matching traffic.
When you allow traffic, you can specify that the system first inspect it with intrusion or file policies to block
any exploits, malware, or prohibited files before they reach your assets or exit your network.
The following scenario summarizes the ways that traffic can be evaluated by access control rules in an inline,
intrusion prevention deployment.

Firepower Management Center Configuration Guide, Version 6.3

1367
 Access Control
Introduction to Access Control Rules

In this scenario, traffic is evaluated as follows:

• Rule 1: Monitor evaluates traffic first. Monitor rules track and log network traffic but do not affect
traffic flow. The system continues to match traffic against additional rules to determine whether to permit
or deny it.
• Rule 2: Trust evaluates traffic next. Matching traffic is allowed to pass to its destination without further
inspection, though it is still subject to identity requirements and rate limiting. Traffic that does not match
continues to the next rule.
• Rule 3: Block evaluates traffic third. Matching traffic is blocked without further inspection. Traffic that
does not match continues to the final rule.
• Rule 4: Allow is the final rule. For this rule, matching traffic is allowed; however, prohibited files,
malware, intrusions, and exploits within that traffic are detected and blocked. Remaining non-prohibited,
non-malicious traffic is allowed to its destination, though it is still subject to identity requirements and
rate limiting. You can configure Allow rules that perform only file inspection, or only intrusion inspection,
or neither.
• Default Action handles all traffic that does not match any of the rules. In this scenario, the default action
performs intrusion prevention before allowing non-malicious traffic to pass. In a different deployment,
you might have a default action that trusts or blocks all traffic, without further inspection. (You cannot
perform file or malware inspection on traffic handled by the default action.)

Traffic you allow, whether with an access control rule or the default action, is automatically eligible for
inspection for host, application, and user data by the network discovery policy. You do not explicitly enable
discovery, although you can enhance or disable it. However, allowing traffic does not automatically guarantee
discovery data collection. The system performs discovery only for connections involving IP addresses that
are explicitly monitored by your network discovery policy; additionally, application discovery is limited for
encrypted sessions.
Note that access control rules handle encrypted traffic when your SSL inspection configuration allows it to
pass, or if you do not configure SSL inspection. However, some access control rule conditions require
unencrypted traffic, so encrypted traffic may match fewer rules. Also, by default, the system disables intrusion
and file inspection of encrypted payloads. This helps reduce false positives and improve performance when
an encrypted connection matches an access control rule that has intrusion and file inspection configured.

Firepower Management Center Configuration Guide, Version 6.3

1368
 Access Control
Recommendations for Application Control

Recommendations for 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

Note 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 that rules based on IP address, for example.
Access control rules that use specific conditions (such as networks and IP addresses) should be ordered before
rules that use general conditions (such as applications). If you're familiar with the Open Systems Interconnect
(OSI) model, use similar numbering in concept. Rules with conditions for layers 1, 2, and 3 (physical, data
link, and network) should be ordered first in your access control rules. Conditions for layers 5, 6, and 7 (session,
presentation, and application) should be ordered later in your access control rules. For more information about
the OSI model, see this Wikipedia article.

The following table provides an example of how to set up your access control rules:

Type of control Action Zones, Users Applications Ports URLs SGT/ISE Inspection,
Networks, Attributes Logging,
VLAN Comments
Tags

Application Your Any Any Do not set Available Any Use only Any
from less secure choice Ports : with
to more secure (Allow in SSH ISE/ISE-PIC.
network when this
Add to
application uses example)
Selected
a port (for
Destination
example, SSH)
Ports

Application Your Any Any Do not set Selected Do Use only Any
from less secure choice Destination not with
to more secure (Allow in Ports set ISE/ISE-PIC.
network when this Protocol:
application does example) ICMP
not use a port
Type: Any
(for example,
ICMP)

Firepower Management Center Configuration Guide, Version 6.3

1369
 Access Control
Access Control Rule Management

Type of control Action Zones, Users Applications Ports URLs SGT/ISE Inspection,
Networks, Attributes Logging,
VLAN Comments
Tags

Application Your Your Choose a Choose the Do not set Do Use only Your
access by a user choice choice user group name of the not with choice
group (Block in (Contractors application set ISE/ISE-PIC.
this group in ( Facebook
example) this in this
example) example)

Access Control Rule Management

The Rules tab of the access control policy editor allows you to add, edit, categorize, search, move, enable,
disable, delete, and otherwise manage access control rules in the current policy.
For each access control rule, the policy editor displays its name, a summary of its conditions, the rule action,
and icons that communicate the rule’s inspection options or status. These icons represent:

• intrusion policy option ( )

• file policy option ( )

• Safe Search option ( )

• YouTube EDU option ( )

• logging option ( )

• Original Client option ( )

• comments ( )

• warnings ( )

• errors ( )

• important information ( )

Disabled rules are dimmed and marked (disabled) beneath the rule name.
To create or edit a rule, use the access control rule editor. You can:
• Configure basic properties such as the rule’s name, state, position, and action in the upper portion of the
editor.
• Add conditions using the tabs on the left side of the lower portion of the editor.
• Use the tabs on the right side of the lower portion to configure inspection and logging options, and also
to add comments to the rule. For your convenience, the editor lists the rule’s inspection and logging
options regardless of which tab you are viewing.

Firepower Management Center Configuration Guide, Version 6.3

1370
 Access Control
Access Control Rule Components

Note Properly creating and ordering access control rules is a complex task, but one that is essential to building an
effective deployment. If you do not plan your policy carefully, rules can preempt other rules, require additional
licenses, or contain invalid configurations. To help ensure that the system handles traffic as you expect, the
access control policy interface has a robust warning and error feedback system for rules.

Related Topics
Access Control Rule Components, on page 1371
Create Custom User Roles, on page 68
Rule Performance Guidelines, on page 352

Access Control Rule Components

In addition to its unique name, each access control rule has the following basic components:

State
By default, rules are enabled. If you disable a rule, the system does not use it and stops generating warnings
and errors for that rule.

Position
Rules in an access control policy are numbered, starting at 1. If you are using policy inheritance, rule 1 is the
first rule in the outermost policy. The system matches traffic to rules in top-down order by ascending rule
number. With the exception of Monitor rules, the first rule that traffic matches is the rule that handles that
traffic.
Rules can also belong to a section and a category, which are organizational only and do not affect rule position.
Rule position goes across sections and categories.

Section and Category

To help you organize access control rules, every access control policy has two system-provided rule sections,
Mandatory and Default. To further organize access control rules, you can create custom rule categories inside
the Mandatory and Default sections.
If you are using policy inheritance, the current policy's rules are nested between its parent policy's Mandatory
and Default sections.

Conditions
Conditions specify the specific traffic the rule handles. Conditions can be simple or complex; their use often
depends on license.

Action
A rule’s action determines how the system handles matching traffic. You can monitor, trust, block, or allow
(with or without further inspection) matching traffic. The system does not perform deep inspection on trusted,
blocked, or encrypted traffic.

Firepower Management Center Configuration Guide, Version 6.3

1371
 Access Control
Access Control Rule Order

Inspection
Deep inspection options govern how the system inspects and blocks malicious traffic you would otherwise
allow. When you allow traffic with a rule, you can specify that the system first inspect it with intrusion or file
policies to block any exploits, malware, or prohibited files before they reach your assets or exit your network.

Logging
A rule’s logging settings govern the records the system keeps of the traffic it handles. You can keep a record
of traffic that matches a rule. In general, you can log sessions at the beginning or end of a connection, or both.
You can log connections to the database, as well as to the system log (syslog) or to an SNMP trap server.

Comments
Each time you save changes to an access control rule, you can add comments.
Related Topics
Rule Performance Guidelines, on page 352
Access Control Rule Management, on page 1370
Creating and Editing Access Control Rules, on page 1374
Rule Condition Types, on page 323
Access Control Rule Actions, on page 1376
About Deep Inspection, on page 1381
Best Practices for Connection Logging, on page 2451
Access Control Rule Comments, on page 1379

Access Control Rule Order

Rules in an access control policy are numbered, starting at 1. The system matches traffic to access control
rules in top-down order by ascending rule number.
In most cases, the system handles network traffic according to the first access control rule where all the rule’s
conditions match the traffic. Except Monitor rules (which log traffic but do not affect traffic flow), the system
does not continue to evaluate traffic against additional, lower-priority rules after that traffic matches a rule.
To help you organize access control rules, every access control policy has two system-provided rule sections,
Mandatory and Default. To further organize, you can create custom rule categories inside the Mandatory or
Default sections. After you create a category, you cannot move it, although you can delete it, rename it, and
move rules into, out of, within, and around it. The system assigns rule numbers across sections and categories.
If you use policy inheritance, the current policy's rules are nested between its parent policy's Mandatory and
Default rule sections. Rule 1 is the first rule in the outermost policy, not the current policy, and the system
assigns rule numbers across policies, sections, and categories.
Any predefined user role that allows you to modify access control policies also allows you to move and modify
access control rules within and among rules categories. You can, however, create custom roles that restrict
users from moving and modifying rules. Any user who is allowed to modify access control policies can add
rules to custom categories and modify rules in them without restriction.

Firepower Management Center Configuration Guide, Version 6.3

1372
 Access Control
Adding an Access Control Rule Category

Tip Proper access control rule order reduces the resources required to process network traffic, and prevents rule
preemption. Although the rules you create are unique to every organization and deployment, there are a few
general guidelines to follow when ordering rules that can optimize performance while still addressing your
needs.

Related Topics
Guidelines for Ordering Rules, on page 353

Adding an Access Control Rule Category

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

You can divide an access control policy's Mandatory and Default rule sections into custom categories. After
you create a category, you cannot move it, although you can delete it, rename it, and move rules into, out of,
within, and around it. The system assigns rule numbers across sections and categories.

Procedure

Step 1 In the access control policy editor, click Add Category.

Tip If your policy already contains rules, you can click a blank area in the row for an existing rule to
set the position of the new category before you add it. You can also right-click an existing rule and
select Insert new category.

Step 2 Enter a Name.

Step 3 From the Insert drop-down list, choose where you want to add the category:
• To insert a category below all existing categories in a section, choose into Mandatory or into Default.
• To insert a category above an existing category, choose above category, then choose a category.
• To insert a category above or below an access control rule, choose above rule or below rule, then enter
an existing rule number.

Step 4 Click OK.

Step 5 Click Save to save the policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1373
 Access Control
Creating and Editing Access Control Rules

Creating and Editing Access Control Rules

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 In the access control policy editor, you have the following options:
• To add a new rule, click Add Rule.

• To edit an existing rule, click the edit icon ( ).

If a view icon ( ) appears next to a rule instead, the rule belongs to an ancestor policy, or you do not have
permission to modify the rule.

Step 2 Enter a Name.

Step 3 Configure the rule components, or accept the defaults:
• Enabled—Specify whether the rule is Enabled.
• Position—Specify the rule position; see Access Control Rule Order, on page 1372.
• Action—Choose a rule Action; see Access Control Rule Actions, on page 1376.
• Conditions—Click the tab corresponding to the condition you want to add. See Rule Condition Types,
on page 323 for more information.

• Deep Inspection—For Allow and Interactive Block rules, click the intrusion inspection icon ( ) or the

file and malware inspection icon ( ) to configure the rule’s Inspection options. If the icon is dimmed,
no policy of that type is selected for the rule. See Access Control Using Intrusion and File Policies, on
page 1381 for more information.

• Content Restriction—Click the Safe Search icon ( ) or YouTube EDU icon ( ) to configure content
restriction settings on the Applications tab of the rule editor. If the icons are dimmed, content restriction
is disabled for the rule. See About Content Restriction, on page 1443 for more information.

• Logging—Click an active (blue) logging icon ( ) to specify Logging options. If the icon is dimmed,
connection logging is disabled for the rule. See Best Practices for Connection Logging, on page 2451 for
more information.
• Comments—Click the number in the comment column to add Comments. The number indicates how
many comments the rule already contains. See Access Control Rule Comments, on page 1379 for more
information.

Firepower Management Center Configuration Guide, Version 6.3

1374
 Access Control
Enabling and Disabling Access Control Rules

Step 4 Save the rule.

Step 5 Click Save to save the policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Rule Performance Guidelines, on page 352

Enabling and Disabling Access Control Rules

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

When you create an access control rule, it is enabled by default. If you disable a rule, the system does not use
it to evaluate network traffic and stops generating warnings and errors for that rule. When viewing the list of
rules in an access control policy, disabled rules are grayed out, although you can still modify them.

Tip You can also enable or disable an access control rule using the rule editor.

Procedure

Step 1 In the access control policy editor, right-click the rule and choose a rule state.

If a view icon ( ) appears next to a rule instead, the rule belongs to an ancestor policy, or you do not have
permission to modify the rule.

Step 2 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Access Control Rule Components, on page 1371

Firepower Management Center Configuration Guide, Version 6.3

1375
 Access Control
Positioning an Access Control Rule

Positioning an Access Control Rule

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

You can move an existing rule within, but not between, access control policies. When you add or move a rule
to a category, the system places it last in the category.

Tip You can move multiple rules at once by selecting the rules then cutting and pasting using the right-click menu.

Procedure

Step 1 In the access control rule editor, you have the following options:
• If you are adding a new rule, use the Insert drop-down list.
• If you are editing an existing rule, click Move.

Step 2 Choose where you want to move or insert the rule:

• Choose into Mandatory or into Default.
• Choose a into Category, then choose the user-defined category.
• Choose above rule or below rule, then type the appropriate rule number.

Step 3 Click Save.

Step 4 Click Save to save the policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Access Control Rule Actions

Every access control rule has an action that determines how the system handles and logs matching traffic.
You can monitor, trust, block, or allow (with or without further inspection).
The access control policy’s default action handles traffic that does not meet the conditions of any non-Monitor
access control rule.

Firepower Management Center Configuration Guide, Version 6.3

1376
 Access Control
Access Control Rule Monitor Action

Access Control Rule Monitor Action

The Monitor action does not affect traffic flow; matching traffic is neither immediately permitted nor denied.
Rather, traffic is matched against additional rules to determine whether to permit or deny it. The first
non-Monitor rule matched determines traffic flow and any further inspection. If there are no additional matching
rules, the system uses the default action.
Because the primary purpose of Monitor rules is to track network traffic, the system automatically logs end-of
connection events for monitored traffic. That is, connections are logged even if the traffic matches no other
rules and you do not enable logging on the default action.

Note If locally-bound traffic matches a Monitor rule in a Layer 3 deployment, that traffic may bypass inspection.
To ensure inspection of the traffic, enable Inspect Local Router Traffic in the advanced device settings for
the managed device routing the traffic.

Related Topics
Logging for Monitored Connections, on page 2446

Access Control Rule Trust Action

The Trust action allows traffic to pass without deep inspection or network discovery. Trusted traffic is still
subject to identity requirements and rate limiting.

Related Topics
Logging for Trusted Connections, on page 2446

Access Control Rule Blocking Actions

The Block and Block with reset actions deny traffic without further inspection of any kind.

Firepower Management Center Configuration Guide, Version 6.3

1377
 Access Control
Access Control Rule Interactive Blocking Actions

Block with reset rules reset the connection, with the exception of web requests met with an HTTP response
page. This is because the response page, which you configure to appear when the system blocks web requests,
cannot display if the connection is immediately reset. For more information, see HTTP Response Pages and
Interactive Blocking, on page 1401.
Related Topics
Logging for Blocked Connections, on page 2447
About HTTP Response Pages, on page 1401

Access Control Rule Interactive Blocking Actions

For more information, see HTTP Response Pages and Interactive Blocking, on page 1401.

If a user bypasses the block, the rule mimics an allow rule. Therefore, you can associate interactive block
rules with file and intrusion policies, and matching traffic is also eligible for network discovery.
If a user does not (or cannot) bypass the block, the rule mimics a block rule. Matching traffic is denied without
further inspection.
Note that if you enable interactive blocking, you cannot reset all blocked connections. This is because the
response page cannot display if the connection is immediately reset. Use the Interactive Block with reset
action to (non-interactively) block-with-reset all non-web traffic, while still enabling interactive blocking for
web requests.
For more information, see HTTP Response Pages and Interactive Blocking, on page 1401.
Related Topics
Logging for Allowed Connections, on page 2448
TLS/SSL Rule Blocking Actions, on page 1493

Firepower Management Center Configuration Guide, Version 6.3

1378
 Access Control
Access Control Rule Allow Action

Access Control Rule Allow Action

The Allow action allows matching traffic to pass, though it is still subject to identity requirements and rate
limiting.
Optionally, you can use deep inspection to further inspect and block unencrypted or decrypted traffic before
it reaches its destination:
• You can use an intrusion policy to analyze network traffic according to intrusion detection and prevention
configurations, and drop offending packets depending on the configuration.
• You can perform file control using a file policy. File control allows you to detect and block your users
from uploading (sending) or downloading (receiving) files of specific types over specific application
protocols.
• You can perform network-based advanced malware protection (AMP), also using a file policy. AMP for
Networks can inspect files for malware, and block detected malware depending on the configuration.

The following diagram illustrates the types of inspection performed on traffic that meets the conditions of an
Allow rule (or a user-bypassed Interactive Block rule. Notice that file inspection occurs before intrusion
inspection; blocked files are not inspected for intrusion-related exploits.

For simplicity, the diagram displays traffic flow for situations where both (or neither) an intrusion and a file
policy are associated with an access control rule. You can, however, configure one without the other. Without
a file policy, traffic flow is determined by the intrusion policy; without an intrusion policy, traffic flow is
determined by the file policy.
Regardless of whether the traffic is inspected or dropped by an intrusion or file policy, the system can inspect
it using network discovery. However, allowing traffic does not automatically guarantee discovery inspection.
The system performs discovery only for connections involving IP addresses that are explicitly monitored by
your network discovery policy; additionally, application discovery is limited for encrypted sessions.
Related Topics
Logging for Allowed Connections, on page 2448

Access Control Rule Comments

When you create or edit an access control rule, you can add a comment. 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

Firepower Management Center Configuration Guide, Version 6.3

1379
 Access Control
Adding Comments to an Access Control Rule

change. You can display a list of all comments for a rule along with the user who added each comment and
the date the comment was added.
When you save a rule, all comments made since the last save become read-only.
Related Topics
Configuring Access Control Policy Preferences

Adding Comments to an Access Control Rule

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 In the access control rule editor, click the Comments tab.
Step 2 Click New Comment.
Step 3 Enter your comment and click OK. You can edit or delete this comment until you save the rule.
Step 4 Click Save.
Step 5 Click Save to save the policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1380
 CHAPTER 64
Access Control Using Intrusion and File Policies
The following topics describe how to configure access control policies to use intrusion and file policies:
• About Deep Inspection, on page 1381
• Access Control Traffic Handling, on page 1382
• File and Intrusion Inspection Order, on page 1383
• Access Control Rule Configuration to Perform Malware Protection, on page 1384
• Access Control Rule Configuration to Perform Intrusion Prevention, on page 1386

About Deep Inspection

Intrusion and file policies work together as the last line of defense before traffic is allowed to its destination:
• Intrusion policies govern the system’s intrusion prevention capabilities.
• File policies govern the system’s file control and AMP for Networks capabilities.

Access control occurs before deep inspection; access control rules and the access control default action
determine which traffic is inspected by intrusion and file policies.
By associating an intrusion or file policy with an access control rule, you are telling the system that before it
passes traffic that matches the access control rule’s conditions, you first want to inspect the traffic with an
intrusion policy, a file policy, or both.

Note By default, the system disables intrusion and file inspection of encrypted payloads. This helps reduce false
positives and improve performance when an encrypted connection matches an access control rule that has
intrusion and file inspection configured.

The system can also receive AMP for Endpoints data from the AMP cloud, then present this data alongside
any AMP for Networks data.
Related Topics
How Policies Examine Traffic For Intrusions, on page 1636
File Policies, on page 1565

Firepower Management Center Configuration Guide, Version 6.3

1381
 Access Control
Access Control Traffic Handling

Access Control Traffic Handling

Access control rules provide a granular method of handling network traffic across multiple managed devices.
The system matches traffic to access control rules in the order you specify. In most cases, the system handles
network traffic according to the first access control rule where all the rule’s conditions match the traffic. An
access control rule’s action determines how the system handles matching traffic. You can monitor, trust,
block, or allow (with or without further inspection) matching traffic.
The following diagram shows the flow of traffic in an inline intrusion prevention and AMP for Networks
deployment, as governed by an access control policy that contains four different types of access control rules
and a default action.

In the scenario above, the first three access control rules in the policy—Monitor, Trust, and Block—cannot
inspect matching traffic. Monitor rules track and log but do not inspect network traffic, so the system continues
to match traffic against additional rules to determine whether to permit or deny it. Trust and Block rules handle
matching traffic without further inspection of any kind, while traffic that does not match continues to the next
access control rule.
The fourth and final rule in the policy, an Allow rule, invokes various other policies to inspect and handle
matching traffic, in the following order:
• Discovery: Network Discovery Policy—First, the network discovery policy inspects traffic for discovery
data. Discovery is passive analysis and does not affect the flow of traffic. Although you do not explicitly
enable discovery, you can enhance or disable it. However, allowing traffic does not automatically guarantee
discovery data collection. The system performs discovery only for connections involving IP addresses
that are explicitly monitored by your network discovery policy.
• AMP for Networks and File Control: File Policy—After traffic is inspected by discovery, the system
can inspect it for prohibited files and malware. AMP for Networks detects and optionally blocks malware
in many types of files, including PDFs, Microsoft Office documents, and others. If your organization
wants to block not only the transmission of malware files, but all files of a specific type (regardless of
whether the files contain malware), file control allows you to monitor network traffic for transmissions
of specific file types, then either block or allow the file.
• Intrusion Prevention: Intrusion Policy—After file inspection, the system can inspect traffic for intrusions
and exploits. An intrusion policy examines decoded packets for attacks based on patterns, and can block

Firepower Management Center Configuration Guide, Version 6.3

1382
 Access Control
File and Intrusion Inspection Order

or alter malicious traffic. Intrusion policies are paired with variable sets, which allow you to use named
values to accurately reflect your network environment.
• Destination—Traffic that passes all the checks described above passes to its destination.

An Interactive Block rule (not shown in the diagram) has the same inspection options as an Allow rule. This
is so you can inspect traffic for malicious content when a user bypasses a blocked website by clicking through
a warning page.
Traffic that does not match any of the non-Monitor access control rules in the policy is handled by the default
action. In this scenario, the default action is an Intrusion Prevention action, which allows traffic to its final
destination as long as it is passed by the intrusion policy you specify. In a different deployment, you might
have a default action that trusts or blocks all traffic without further inspection. Note that the system can inspect
traffic allowed by the default action for discovery data and intrusions, but not prohibited files or malware.
You cannot associate a file policy with the access control default action.

Note Sometimes, when a connection is analyzed by an access control policy, the system must process the first few
packets in that connection, allowing them to pass, before it can decide which access control rule (if any) will
handle the traffic. However, so these packets do not reach their destination uninspected, you can use an
intrusion policy—called the default intrusion policy—to inspect them and generate intrusion events.

File and Intrusion Inspection Order

In your access control policy, you can associate multiple Allow and Interactive Block rules with different
intrusion and file policies to match inspection profiles to various types of traffic.

Note Traffic allowed by an Intrusion Prevention or Network Discovery Only default action can be inspected for
discovery data and intrusions, but cannot be inspected for prohibited files or malware. You cannot associate
a file policy with the access control default action.

You do not have to perform both file and intrusion inspection in the same rule. For a connection matching an
Allow or Interactive Block rule:
• without a file policy, traffic flow is determined by the intrusion policy
• without an intrusion policy, traffic flow is determined by the file policy
• without either, allowed traffic is inspected by network discovery only

Tip The system does not perform any kind of inspection on trusted traffic. Although configuring an Allow rule
with neither an intrusion nor file policy passes traffic like a Trust rule, Allow rules let you perform discovery
on matching traffic.

The diagram below illustrates the types of inspection you can perform on traffic that meets the conditions of
either an Allow or user-bypassed Interactive Block access control rule. For simplicity, the diagram displays

Firepower Management Center Configuration Guide, Version 6.3

1383
 Access Control
Access Control Rule Configuration to Perform Malware Protection

traffic flow for situations where both (or neither) an intrusion and a file policy are associated with a single
access control rule.

For any single connection handled by an access control rule, file inspection occurs before intrusion inspection.
That is, the system does not inspect files blocked by a file policy for intrusions. Within file inspection, simple
blocking by type takes precedence over malware inspection and blocking.
For example, consider a scenario where you normally want to allow certain network traffic as defined in an
access control rule. However, as a precaution, you want to block the download of executable files, examine
downloaded PDFs for malware and block any instances you find, and perform intrusion inspection on the
traffic.
You create an access control policy with a rule that matches the characteristics of the traffic you want to
provisionally allow, and associate it with both an intrusion policy and a file policy. The file policy blocks the
download of all executables, and also inspects and blocks PDFs containing malware:
• First, the system blocks the download of all executables, based on simple type matching specified in the
file policy. Because they are immediately blocked, these files are subject to neither malware nor intrusion
inspection.
• Next, the system performs malware cloud lookups for PDFs downloaded to a host on your network. Any
PDFs with a malware disposition are blocked, and are not subject to intrusion inspection.
• Finally, the system uses the intrusion policy associated with the access control rule to inspect any remaining
traffic, including files not blocked by the file policy.

Note Until a file is detected and blocked in a session, packets from the session may be subject to intrusion inspection.

Access Control Rule Configuration to Perform Malware

Protection
An access control policy can have multiple access control rules associated with file policies. You can configure
file inspection for any Allow or Interactive Block access control rule, which permits you to match different
file and malware inspection profiles against different types of traffic on your network before it reaches its
final destination.

Firepower Management Center Configuration Guide, Version 6.3

1384
 Access Control
Configuring an Access Control Rule to Perform Malware Protection

When the system detects a prohibited file (including malware) according to the settings in the file policy, it
automatically logs an event to the Firepower Management Center database. If you do not want to log file or
malware events, you can disable this logging on a per-access-control-rule basis.
The system also logs the end of the associated connection to the Firepower Management Center database,
regardless of the logging configuration of the invoking access control rule.

Configuring an Access Control Rule to Perform Malware Protection

Smart License Classic License Supported Devices Supported Domains Access

Threat (file control) Protection (file Any Any Admin/Access

Malware (AMP) control) Admin/Network
Malware (AMP) Admin

Caution Enabling or disabling Store files in a Detect Files or Block Files rule, or adding the first or removing the last
file rule that combines the Malware Cloud Lookup or Block Malware file rule action with an analyis option
(Spero Analysis or MSEXE, Dynamic Analysis, or Local Malware Analysis) or a store files option
(Malware, Unknown, Clean, or Custom), restarts the Snort process when you deploy configuration changes,
temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without
further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior, on
page 312 for more information.

Before you begin

• Adaptive profiling must be enabled (its default state) as described in Configuring Adaptive Profiles, on
page 2003 for access control rules to perform file control, including AMP.

Procedure

Step 1 In the access control rule editor, choose an Action of Allow, Interactive Block, or Interactive Block with
reset.
Step 2 Click the Inspection tab.
Step 3 Choose a Malware Policy (file policy) to inspect traffic that matches the access control rule, or choose None
to disable file inspection for matching traffic.
Step 4 (Optional) Disable logging of file or malware events for matching connections by clicking the Logging tab
and unchecking Log Files.
Note Cisco recommends you leave file and malware event logging enabled.

Step 5 Save the rule.

Step 6 Click Save to save the policy.

Firepower Management Center Configuration Guide, Version 6.3

1385
 Access Control
Access Control Rule Configuration to Perform Intrusion Prevention

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Creating a File Policy, on page 1567
Snort® Restart Scenarios, on page 311

Access Control Rule Configuration to Perform Intrusion

Prevention
An access control policy can have multiple access control rules associated with intrusion policies. You can
configure intrusion inspection for any Allow or Interactive Block access control rule, which permits you to
match different intrusion inspection profiles against different types of traffic on your network before it reaches
its final destination.
Whenever the system uses an intrusion policy to evaluate traffic, it uses an associated variable set. Variables
in a set 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 and
dynamic rule states.

Tip Even if you use system-provided intrusion policies, Cisco strongly recommends you configure the system’s
intrusion variables to accurately reflect your network environment. At a minimum, modify default variables
in the default set.

Understanding System-Provided and Custom Intrusion Policies

Cisco delivers several intrusion policies with the Firepower System. By using system-provided intrusion
policies, you can take advantage of the experience of theCisco Talos Security Intelligence and Research Group
(Talos). For these policies, Talos sets intrusion and preprocessor rule states, as well as provides the initial
configurations for advanced settings. You can use system-provided policies as-is, or you can use them as the
base for custom policies. Building custom policies can improve the performance of the system in your
environment and provide a focused view of the malicious traffic and policy violations occurring on your
network.

Connection and Intrusion Event Logging

When an intrusion policy invoked by an access control rule detects an intrusion and generates an intrusion
event, it saves that event to the Firepower Management Center. The system also automatically logs the end
of the connection where the intrusion occurred to the Firepower Management Center database, regardless of
the logging configuration of the access control rule.
Related Topics
Predefined Default Variables, on page 384

Firepower Management Center Configuration Guide, Version 6.3

1386
 Access Control
Access Control Rule Configuration and Intrusion Policies

Access Control Rule Configuration and Intrusion Policies

In addition to custom intrusion policies that you create, the system provides two custom policies: Initial Inline
Policy and Initial Passive Policy. These two intrusion policies use the Balanced Security and Connectivity
intrusion policy as their base. The only difference between them is their Drop When Inline setting, which
enables drop behavior in the inline policy and disables it in the passive policy.
The number of unique intrusion policies you can use in a single access control policy depends on the model
of the target devices; more powerful devices can handle more. Every unique pair of intrusion policy and
variable set counts as one policy. Although you can associate a different intrusion policy-variable set pair
with each Allow and Interactive Block rule (as well as with the default action), you cannot deploy an access
control policy if the target devices have insufficient resources to perform inspection as configured.

Configuring an Access Control Rule to Perform Intrusion Prevention

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 In the access control policy editor, create a new rule or edit an existing rule; see Access Control Rule
Components, on page 1371.
Step 2 Ensure the rule action is set to Allow, Interactive Block, or Interactive Block with reset.
Step 3 Click the tab.
Step 4 Choose a system-provided or custom Intrusion Policy, or choose None to disable intrusion inspection for
traffic that matches the access control rule.
Step 5 If you want to change the variable set associated with the intrusion policy, choose a value from the Variable
Set drop-down list.
Step 6 Click Save to save the rule.
Step 7 Click Save to save the policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Variable Sets, on page 382
Snort® Restart Scenarios, on page 311

Firepower Management Center Configuration Guide, Version 6.3

1387
 Access Control
Configuring an Access Control Rule to Perform Intrusion Prevention

Firepower Management Center Configuration Guide, Version 6.3

1388
 CHAPTER 65
URL Filtering
• URL Filtering Overview, on page 1389
• About URL Filtering with Category and Reputation, on page 1389
• Guidelines and Limitations for URL Filtering, on page 1390
• How to Configure URL Filtering with Category and Reputation, on page 1393
• Configure URL Filtering Health Monitors, on page 1398
• Manual URL Filtering, on page 1398
• Troubleshoot URL Filtering, on page 1399
• History for URL Filtering, on page 1400

URL Filtering Overview

Use the URL filtering feature to control the websites that users on your network can access:
• Category and reputation-based URL filtering—With a URL Filtering license, you can control access to
websites based on the URL’s general classification (category) and risk level (reputation). This is the
recommended option.
• Manual URL filtering—With any license, you can manually specify individual URLs, groups of URLs,
and URL lists and feeds to achieve granular, custom control over web traffic. For more information, see
Manual URL Filtering, on page 1398.

About URL Filtering with Category and Reputation

With a URL Filtering license, you can control access to websites based on the category and reputation of
requested URLs:
• Category—A general classification for the URL. For example, ebay.com belongs to the Auctions category,
and monster.com belongs to the Job Search category. A URL can belong to more than one category.
• Reputation—How likely the URL is to be used for purposes that might be against your organization’s
security policy. Reputations range from High Risk (level 1) to Well Known (level 5).

Firepower Management Center Configuration Guide, Version 6.3

1389
 Access Control
URL Filtering Data from the Cisco Cloud

Benefits of Category and Reputation-Based URL Filtering

URL categories and reputations help you quickly configure URL filtering. For example, you can use access
control to block high risk URLs in the Abused Drugs category. Or, you can use QoS to rate limit traffic from
sites in the Streaming Media category. There are also categories for types of threats, such as a Spyware and
Adware category.
Using category and reputation data simplifies policy creation and administration. It grants you assurance that
the system controls web traffic as expected. Because Cisco continually updates its threat intelligence with
new URLs, as well as new categories and risks for existing URLs, you can ensure that the system uses
up-to-date information to filter requested URLs. Sites that (for example) represent security threats, or that
serve undesirable content, may appear and disappear faster than you can update and deploy new policies.
Some examples of how the system can adapt include:
• If an access control rule blocks all gaming sites, as new domains get registered and classified as Gaming,
the system can block those sites automatically. Similarly, if a QoS rule rate limits all streaming media
sites, the system can automatically limit traffic to new Streaming Media sites.
• If an access control rule blocks all malware sites and a blog page gets infected with malware, the system
can recategorize the URL from Blog to Malware and block that site.
• If an access control rule blocks high-risk social networking sites and somebody posts a link on their
profile page that contains links to malicious payloads, the system can change the reputation of that page
from Benign Sites to High Risk and block it.

Related Topics
Snort® Restart Scenarios, on page 311

URL Filtering Data from the Cisco Cloud

URL filtering based on category and reputation requires a data set provided by Cisco Collective Security
Intelligence (Cisco CSI), a cloud service.
Generally, by default, when a valid URL Filtering license is applied to an active device, the URL category
and reputation data set is downloaded from the Cisco CSI cloud to the Firepower Management Center and
pushed to devices. This locally stored data set is updated periodically.
When a user on the network accesses a URL, the system looks for a match in the local (downloaded) data set.
If there is no match, the system checks a cache of results that the system previously looked up in the Cisco
CSI cloud. If there is still no match, the system looks up the URL in the Cisco CSI cloud and adds the result
to the cache.

Guidelines and Limitations for URL Filtering

Speed of URL Identification
The system cannot filter URLs before:
• A monitored connection is established between a client and server.
• The system identifies the HTTP or HTTPS application in the session.

Firepower Management Center Configuration Guide, Version 6.3

1390
Access Control
Guidelines and Limitations for URL Filtering

• The system identifies the requested URL (for encrypted sessions, from either the ClientHello message
or the server certificate).

This identification should occur within 3 to 5 packets, or after the server certificate exchange in the TLS/SSL
handshake if the traffic is encrypted.
If early traffic matches all other rule conditions but identification is incomplete, the system allows the packet
to pass and the connection to be established (or the TLS/SSL handshake to complete). After the system
completes its identification, the system applies the appropriate rule action to the remaining session traffic.
For access control, these passed packets are inspected by the access control policy’s default intrusion
policy—not the default action intrusion policy nor the almost-matched rule’s intrusion policy.

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.

For additional guidelines for rules, see the Rule Management: Common Characteristics, on page 321 chapter,
including the following topics: Rule Condition Mechanics, on page 324 and Rule Performance Guidelines, on
page 352.

Uncategorized/Reputationless URLs
If the system does not know the category and reputation of a URL, browsing to that website does not match
rules with category and reputation-based URL conditions. You cannot assign categories and reputations to
URLs manually.
When you build a URL rule, you first choose the category you want to match. If you explicitly choose
Uncategorized URLs, you cannot further constrain by reputation, because uncategorized URLs do not have
reputations.

URL Filtering for Encrypted Web Traffic

When performing URL filtering on encrypted web traffic, the system:
• Disregards the encryption protocol; a rule matches both HTTPS and HTTP traffic if the rule has a URL
condition but not an application condition that specifies the protocol.
• Does not use URL lists. You must use URL objects and groups instead.
• Matches HTTPS traffic based on the subject common name in the public key certificate used to encrypt
the traffic, and disregards subdomains within the subject common name.
• Does not display an HTTP response page for encrypted connections blocked by access control rules (or
any other configuration); see Limitations to HTTP Response Pages, on page 1401.

HTTP/2
The system can extract HTTP/2 URLs from TLS certificates, but not from a payload.

Firepower Management Center Configuration Guide, Version 6.3

1391
 Access Control
Filtering HTTPS Traffic

Search Query Parameters in URLs

The system does not use search query parameters in the URL to match URL conditions. For example, consider
a scenario where you block all shopping traffic. In that case, using a web search to search for amazon.com is
not blocked, but browsing to amazon.com is.

URL Filtering in High Availability Deployments

For guidelines for URL filtering with Firepower Management Centers in high availability, see URL Filtering
and Security Intelligence, on page 480.

Memory Limitations for Selected Device Models

Due to memory limitations, some device models perform most URL filtering with a smaller, less granular,
set of categories and reputations. For example, even if a parent URL's subsites have different URL categories
and reputations, some devices may only store the parent URL's data. For web traffic handled by these devices,
the system may perform cloud lookups to determine category and reputation for sites not in the local database.
Lower-memory devices include:
• 7100 series
• ASA 5508-X and ASA 5516-X
• ASA 5515-X and ASA 5525-X

If you are using NGIPSv, see the Cisco Firepower NGIPSv for VMware Quick Start Guide for information
on allocating the correct amount of memory to perform category and reputation-based URL filtering.

Manual URL Filtering

When manually filtering specific URLs, carefully consider other traffic that might be affected. To determine
whether network traffic matches a URL condition, the system performs a simple substring match. If the
requested URL matches any part of the string, the URLs are considered to match.
Related Topics
The Default Intrusion Policy, on page 1857

Filtering HTTPS Traffic

To filter encrypted traffic, the system determines the requested URL based on information passed during the
TLS/SSL handshake: the subject common name in the public key certificate used to encrypt the traffic.
HTTPS filtering, unlike HTTP filtering, disregards subdomains within the subject common name. Do not
include subdomain information when manually filtering HTTPS URLs in access control or QoS policies. For
example, use example.com rather than www.example.com.
HTTPS filtering also does not support URL lists. You must use URL objects and groups instead.

Tip In an SSL policy, you can handle and decrypt traffic to specific URLs by defining a distinguished name SSL
rule condition. The common name attribute in a certificate’s subject distinguished name contains the site’s
URL. Decrypting HTTPS traffic allows access control rules to evaluate the decrypted session, which improves
URL filtering.

Firepower Management Center Configuration Guide, Version 6.3

1392
 Access Control
How to Configure URL Filtering with Category and Reputation

Controlling Traffic by Encryption Protocol

The system disregards the encryption protocol (HTTP vs HTTPS) when performing URL filtering in access
control or QoS policies. This occurs for both manual and reputation-based URL conditions. In other words,
URL filtering treats traffic to the following websites identically:
• http://example.com/
• https://example.com/

To configure a rule that matches only HTTP or HTTPS traffic, add an application condition to the rule. For
example, you could allow HTTPS access to a site while disallowing HTTP access by constructing two access
control rules, each with an application and URL condition.
The first rule allows HTTPS traffic to the website:
Action: Allow
Application: HTTPS
URL: example.com
The second rule blocks HTTP access to the same website:
Action: Block
Application: HTTP
URL: example.com

How to Configure URL Filtering with Category and Reputation

Do This More Information

Step 1 If you will use category and Cisco Firepower NGIPSv for VMware Quick Start Guide
reputation-based URL filtering on an
NGIPSv device, allocate the required
amount of memory.

Step 2 Ensure that you have the correct licenses. Licensing the Firepower System, on page 79, including
URL Filtering Licenses for Firepower Threat Defense
Devices, on page 89 and URL Filtering Licenses for
Classic Devices, on page 123.
Assign the URL Filtering license to each managed device
that will filter URLs.

Step 3 Ensure that your Firepower Management Internet Access Requirements, on page 2679 and
Center can communicate with the cloud Communication Port Requirements, on page 2681.
to obtain URL filtering data.

Step 4 Understand limitations and guidelines and Guidelines and Limitations for URL Filtering, on page
take any necessary actions. 1390

Step 5 Enable the URL Filtering feature. Enable URL Filtering Using Category and Reputation,
on page 1394

Firepower Management Center Configuration Guide, Version 6.3

1393
 Access Control
Enable URL Filtering Using Category and Reputation

Do This More Information

Step 6 Configure policies to filter URLs by Configuring URL Conditions, on page 1395, including the
category and reputation. information preceding Step 1, and URL Rule Order, on
page 356

Step 7 Ensure that your system receives future Configure URL Filtering Health Monitors, on page 1398
URL data updates as expected.

Enable URL Filtering Using Category and Reputation

Smart License Classic License Supported Devices Supported Domains Access

URL Filtering URL Filtering Any Any Admin

Before you begin

Complete prerquisites described in How to Configure URL Filtering with Category and Reputation, on page
1393.

Procedure

Step 1 Choose System > Integration.

Step 2 Click the Cisco CSI tab.
Step 3 Configure URL Filtering Options, on page 1394.
Step 4 Click Save.

URL Filtering Options

Enable URL Filtering

Allows traffic filtering based on a website’s general classification, or category, and risk level, or reputation.
Adding a URL Filtering license automatically enables Enable URL Filtering. URL filtering must be enabled
before you can choose other URL filtering options.
When you enable URL filtering, depending on how long since URL filtering was last enabled, or if this is the
first time you are enabling URL filtering, the Firepower Management Center downloads URL data from Cisco
Collective Security Intelligence (Cisco CSI). This process may take some time.

Enable Automatic Updates

Options for updating URL filtering threat data:
• If you enable the Enable Automatic Updates option on this page, the Firepower Management Center
checks the cloud every 30 minutes for updates. This option is enabled by default when you add a URL
filtering license.

Firepower Management Center Configuration Guide, Version 6.3

1394
 Access Control
Configuring URL Conditions

• If you need strict control over when the system contacts external resources, disable automatic updates
on this page and instead create a recurring task using the scheduler. See Automating URL Filtering
Updates Using a Scheduled Task, on page 208.

Update Now
You can perform a one-time, on-demand update by clicking the Update Now button at the top of this dialog
box, but you should also either enable automatic updates or create a recurring task using the scheduler. You
cannot start an on-demand update if an update is already in progress.
Although daily updates tend to be small, if it has been more than five days since your last update, new URL
data may take up to 20 minutes to download, depending on your bandwidth. Then, it may take up to 30 minutes
to perform the update itself.

Query Cisco CSI for Unknown URLs

Allows the system to submit URLs to the cloud for threat intelligence evaluation when users browse to a
website whose category and reputation are not in the local dataset. Disable this option if you do not want to
submit your uncategorized URLs, for example, for privacy reasons.
This option is enabled by default if at least one managed device has a valid URL Filtering license.
Connections to uncategorized URLs do not match rules with category or reputation-based URL conditions.
You cannot assign categories or reputations to URLs manually.
If you use SSL rules to handle encrypted traffic, see also TLS/SSL Rule Guidelines and Limitations, on page
1483.

Cached URLs Expire

This option applies only to devices running release 6.3 or higher. For devices running release 6.2.3, you must
contact TAC to configure this functionality.
This setting is relevant only if Query Cisco CSI for Unknown URLs is enabled.
Caching category and reputation data makes web browsing faster. By default, cached data for URLs never
expires, for fastest performance.
To minimize instances of URLs matching on stale data, you can set URLs in the cache to expire. For greater
accuracy and currency of threat data, choose a shorter expiration time.
A cached URL refreshes after the first time a user on the network accesses it after the specified time has
passed. The first user does not see the refreshed result, but the next user who visits this URL does see the
refreshed result.
For more information about caching of URL data, see URL Filtering Data from the Cisco Cloud , on page
1390.

Configuring URL Conditions

Smart License Classic License Supported Devices Supported Domains Access

URL Filtering URL Filtering Any Any Admin/Access

(cat/rep) (cat/rep) Admin/Network
Admin
Any (manual) Any (manual)

Firepower Management Center Configuration Guide, Version 6.3

1395
 Access Control
Configuring URL Conditions

When you build a URL condition, you choose the URL categories whose traffic you want to control. Optionally,
you can constrain those URL categories with a reputation.
In access control and QoS rules, you can also filter individual URLs using predefined URL objects, URL lists
and feeds, and manual per-rule URLs. You cannot constrain these URLs with a reputation. Manual URL
filtering is not supported in SSL rules; instead, use distinguished name conditions.

Procedure

Step 1 In the rule editor, click the tab for URL conditions:
• Access control or QoS—Click the URLs tab.
• SSL—Click the Category tab.

Step 2 Find and choose the URLs you want to control:

• Categories—Choose URL categories, or keep the default of Any. In an access control or QoS rule, click
the Category sub-tab to choose categories.
• URL Objects, Lists, and Feeds—Choose predefined URL objects and URL lists and feeds. In an access
control or QoS rule, click the URLs sub-tab to choose URLs.

Step 3 (Optional) Constrain URL categories by choosing a Reputation.

Note that if you explicitly match Uncategorized URLs, you cannot further constrain by reputation, because
uncategorized URLs do not have reputations. Choosing a reputation level also includes other reputations either
more or less severe than the level you choose, depending on the rule action:
• Includes less severe reputations—If the rule allows or trusts web traffic. For example, if you configure
an access control rule to allow Benign Sites (level 4), it also automatically allows Well Known (level 5)
sites.
• Includes more severe reputations—If the rule rate limits, decrypts, blocks, or monitors web traffic. For
example, if you configure an access control rule to block Suspicious Sites (level 2), it also blocks High
Risk (level 1) sites.

If you change the rule action, the system automatically changes the reputation levels in URL conditions.

Step 4 Click Add to Rule, or drag and drop.

Step 5 (Optional) In an access control or QoS rule, add any URLs that you want to specify manually by entering a
URL and clicking Add.
You can enter a URL or IP address. This field does not support wildcards.

Step 6 Save or continue editing the rule.

Example: URL Condition in an Access Control Rule

The following graphic shows the URL condition for an access control rule that blocks all malware
sites, all high-risk sites, and all non-benign social networking sites. It also blocks a single site,
example.com, which is represented by a URL object.

Firepower Management Center Configuration Guide, Version 6.3

1396
 Access Control
Rules with URL Conditions

The following table summarizes how you build the condition.

Blocked URL Category or URL Object Reputation

Malware sites, regardless of Malware Sites Any

reputation

Any URL with a high risk (level 1) Any 1 - High Risk

Social networking sites with a risk Social Network 3 - Benign sites with security risks
greater than benign (levels 1
through 3)

example.com The URL object named None

example.com

What to do next
• If you are configuring an access control policy to filter by URL category, specify how to handle access
to URLs that require cloud lookups. See information about the Retry URL cache miss lookup option
in Access Control Policy Advanced Settings, on page 1362.
• When you block web traffic, you can allow the user’s browser its default behavior, or you can display a
generic system-provided or custom HTTP response page. Interactive blocking gives users a chance to
bypass a website block by clicking through a warning page. For more information, see HTTP Response
Pages and Interactive Blocking, on page 1401.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Rules with URL Conditions

The following table lists rules that support URL conditions, and the types of filtering that each rule type
supports.

Rule Type Supports Cat. and Rep. Filtering? Supports Manual Filtering?

Access control yes yes

SSL yes no; use distinguished name conditions

instead

QoS yes yes

Firepower Management Center Configuration Guide, Version 6.3

1397
 Access Control
URL Rule Order

URL Rule Order

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.

Configure URL Filtering Health Monitors

The following health policies alert if the system has problems obtaining or updating URL category and
reputation data.
• URL Filtering Monitor
• Threat Data Updates on Device

To ensure that these are configured the way you want them, see Health Modules, on page 240 and Configuring
Health Monitoring, on page 247.

Manual URL Filtering

In access control and QoS rules, you can supplement or selectively override category and reputation-based
URL filtering by manually filtering individual URLs, groups of URLs, or URL lists and feeds.

Note To filter a large number of URLs, use a URL list instead of individual or grouped URL objects. For more
information, see Security Intelligence Lists and Feeds, on page 398.

You can perform this type of URL filtering without a special license. Manual URL filtering is not supported
in SSL rules; instead, use distinguished name conditions.
For example, you might use access control to block a category of websites that are not appropriate for your
organization. However, if the category contains a website that is appropriate, and to which you want to provide
access, you can create a manual Allow rule for that site and place it before the Block rule for the category.
When manually filtering specific URLs, carefully consider other traffic that might be affected. To determine
whether network traffic matches a URL condition, the system performs a simple substring match. If the
requested URL matches any part of the string, the URLs are considered to match.
For example, if you allow all traffic to example.com, your users could browse to URLs including:
• http://example.com/
• http://example.com/newexample
• http://www.example.com/

As another example, consider a scenario where you want to explicitly block ign.com (a gaming site). However,
substring matching means that blocking ign.com also blocks verisign.com, which might not be your intent.

Firepower Management Center Configuration Guide, Version 6.3

1398
 Access Control
Troubleshoot URL Filtering

Related Topics
Security Intelligence Lists and Feeds, on page 398

Troubleshoot URL Filtering

How can I find the category and reputation of a particular URL?
Do a manual lookup. See Finding URL Category and Reputation, on page 2344.

Error when attempting a manual lookup: "Cloud Lookup Failure for <URL>"
Make sure the feature is properly enabled. See the prerequisites in Finding URL Category and Reputation,
on page 2344.

URL appears to be incorrectly handled based on its URL category and reputation
Problem: The system does not handle the URL correctly based on its URL category and reputation.
Solutions:
• Verify that the URL category and reputation associated with the URL are what you think they are. See
Finding URL Category and Reputation, on page 2344.
• The following issues may be addressed by settings described in URL Filtering Options, on page 1394,
accessible using Enable URL Filtering Using Category and Reputation, on page 1394.
• The URL cache may hold stale information. See information about the Cached URLs Expire
setting.
• The local data set may not be updated with current information from the cloud. See information
about the Enable Automatic Updates setting in URL Filtering Options, on page 1394.
• The system may be configured to not check the cloud for current data. See information about the
Query Cisco CSI for Unknown URLs setting in URL Filtering Options, on page 1394.

• Your access control policy may be configured to pass traffic to the URL without checking the cloud. See
information about the Retry URL cache miss lookup setting in Access Control Policy Advanced Settings,
on page 1362.
• See also Guidelines and Limitations for URL Filtering, on page 1390.
• If the URL is processed using an SSL rule, see TLS/SSL Rule Guidelines and Limitations, on page 1483
and SSL Rule Order, on page 355
• Verify that the URL is being handled using the access control rule that you think it is being handled by,
and that the rule does what you think it does.
• Verify that the local URL category and reputation database on the Firepower Management Center is
successfully being updated from the cloud and that managed devices are successfully being updated from
the Firepower Management Center.
Status of these processes are reported in the Health Monitor, in the URL Filtering Monitor module and
the Threat Data Updates on Devices module. For details, see Health Monitoring, on page 239.

Firepower Management Center Configuration Guide, Version 6.3

1399
 Access Control
History for URL Filtering

If you want to immediately update the local URL category and reputation database, go to System > Integration,
click the Cisco CSI tab, then click Update Now. For more information, see URL Filtering Options, on page
1394.

Web pages are slow to load

There is a tradeoff between security and performance. Some options:
• Consider modifying the Cached URLs Expire setting. Click System > Integration, then select the
Cisco CSI tab. For information, see URL Filtering Options, on page 1394.
• Consider deselecting the Retry URL cache miss lookup setting in Access Control Policy Advanced
Settings, on page 1362.

History for URL Filtering

Feature Version Details

Moved URL Filtering information from 6.3 Moved information about configuring cloud
various locations to this new URL Filtering communications for URL Filtering to the
chapter new URL Filtering chapter. Moved certain
other URL Filtering information from other
locations to this chapter. Made related
changes to the structure of the Cisco CSI
topics in the chapter.

New option: Cached URLs Expire 6.3 Use this new control to balance
performance with freshness of URL
category and reputation data in order to
minimize instances of URLs matching on
stale data.
Modified screens: System > Integration
> Cisco CSI.
Supported Platforms: All.

Changed menu path 6.3 The path to the manual URL Lookup page
has changed from Analysis > Lookup >
URL to Analysis > Advanced > URL.

Firepower Management Center Configuration Guide, Version 6.3

1400
 CHAPTER 66
HTTP Response Pages and Interactive Blocking
The following topics describe how to configure custom pages to display when the system blocks web requests:
• About HTTP Response Pages, on page 1401
• Choosing HTTP Response Pages, on page 1402
• Interactive Blocking with HTTP Response Pages, on page 1403

About HTTP Response Pages

As part of access control, you can configure an HTTP response page to display when the system blocks web
requests, using either access control rules or the access control policy default action.
The response page displayed depends on how you block the session:
• Block Response Page: Overrides the default browser or server page that explains that the connection
was denied.
• Interactive Block Response Page: Warns users, but also allows them to click a button (or refresh the
page) to load the originally requested site. Users may have to refresh after bypassing the response page
to load page elements that did not load.

If you do not choose a response page, the system blocks sessions without interaction or explanation.

Limitations to HTTP Response Pages

Response Pages are for Access Control Rules/Default Action Only
The system displays a response page only for unencrypted or decrypted HTTP/HTTPS connections blocked
(or interactively blocked) either by access control rules or by the access control policy default action. The
system does not display a response page for connections blocked or blacklisted by any other policy or
mechanism.

Displaying the Response Page Disables Connection Reset

The system cannot display a response page if the connection is reset (RST packet sent). If you enable response
pages, the system prioritizes that configuration. Even if you choose Block with reset or Interactive Block
with reset as the rule action, the system displays the response page and does not reset matching web
connections. To ensure that blocked web connections reset, you must disable response pages.

Firepower Management Center Configuration Guide, Version 6.3

1401
 Access Control
Choosing HTTP Response Pages

Note that all non-web traffic that matches the rule is blocked with reset.

No Response Page for Encrypted Connections (Must Decrypt)

The system does not display a response page for encrypted connections blocked by access control rules (or
any other configuration). Access control rules evaluate encrypted connections if you did not configure an SSL
policy, or your SSL policy passes encrypted traffic.
For example, the system cannot decrypt HTTP/2 or SPDY sessions. If web traffic encrypted using one of
these protocols reaches access control rule evaluation, the system does not display a response page if the
session is blocked.
However, the system does display a response page for connections decrypted by the SSL policy, then blocked
(or interactively blocked) either by access control rules or by the access control policy default action. In these
cases, the system encrypts the response page and sends it at the end of the reencrypted SSL stream.

No Response Page for "Promoted" Connections

The system does not display a response page when web traffic is blocked as a result of a promoted access
control rule (an early-placed blocking rule with only simple network conditions).

No Response Page Before URL Identification

The system does not display a response page when web traffic is blocked before the system identifies the
requested URL; see Guidelines and Limitations for URL Filtering, on page 1390.

Choosing HTTP Response Pages

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Reliable display of HTTP response pages depends on your network configuration, traffic loads, and size of
the page. Smaller pages are more likely to display successfully.

Procedure

Step 1 In the access control policy editor, click the HTTP Responses tab.
If the controls are dimmed, settings are inherited from an ancestor policy, or you do not have permission to
modify the configuration. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.

Step 2 Choose the Block Response Page and Interactive Block Response Page:

• System-provided—Displays a generic response. Click the view icon ( ) to view the code for this page.
• Custom—Create a custom response page. A pop-up window appears, prepopulated with system-provided
code that you can replace or modify by clicking the edit icon ( ). A counter shows how many characters
you have used.

Firepower Management Center Configuration Guide, Version 6.3

1402
 Access Control
Interactive Blocking with HTTP Response Pages

• None—Disables the response page and blocks sessions without interaction or explanation. To quickly
disable interactive blocking for the whole access control policy, choose this option.

Step 3 Click Save to save the policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Interactive Blocking with HTTP Response Pages

When you configure interactive blocking, users can load an originally requested site after reading a warning.
Users may have to refresh after bypassing the response page to load page elements that did not load.

Tip To quickly disable interactive blocking for the whole access control policy, display neither the system-provided
page nor a custom page. The system then blocks all connections without interaction.

If a user does not bypass an interactive block, matching traffic is denied without further inspection. If a user
bypasses an interactive block, the access control rule allows the traffic, although the traffic may still be subject
to deep inspection and blocking.
By default, a user bypass is in effect for 10 minutes (600 seconds) without displaying the warning page on
subsequent visits. You can set the duration to as long as a year, or you can force the user to bypass the block
every time. This limit applies to every Interactive Block rule in the policy. You cannot set the limit per rule.
Logging options for interactively blocked traffic are identical to those in allowed traffic, but if a user does
not bypass the interactive block, the system can log only beginning-of-connection events. When the system
initially warns the user, it marks any logged beginning-of-connection event with the Interactive Block
or Interactive Block with reset action. If the user bypasses the block, additional connection
events logged for the session have an action of Allow.

Configuring Interactive Blocking

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin

Access Admin
Network Admin

Procedure

Step 1 As part of access control, configure an access control rule that matches web traffic; see Creating and Editing
Access Control Rules, on page 1374:
• Action—Set the rule action to Interactive Block or Interactive Block with reset; see Access Control
Rule Interactive Blocking Actions, on page 1378.

Firepower Management Center Configuration Guide, Version 6.3

1403
 Access Control
Setting the User Bypass Timeout for a Blocked Website

• Conditions—Use URL conditions to specify the web traffic to interactively block; see URL Conditions
(URL Filtering), on page 342.
• Logging—Assume users will bypass the block and choose logging options accordingly; see Logging for
Allowed Connections, on page 2448.
• Inspection—Assume users will bypass the block and choose deep inspection options accordingly; see
Access Control Using Intrusion and File Policies, on page 1381.

Step 2 (Optional) On the access control policy HTTP Responses tab, choose a custom interactive-block HTTP
response page; see Choosing HTTP Response Pages, on page 1402.
Step 3 (Optional) On the access control policy Advanced tab, change the user bypass timeout; see Setting the User
Bypass Timeout for a Blocked Website, on page 1404.
After a user bypasses a block, the system allows the user to browse to that page without warning until the
timeout period elapses.

Step 4 Save the access control policy.

Step 5 Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Setting the User Bypass Timeout for a Blocked Website

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 In the access control policy editor, click the Advanced tab.

Step 2 Click the edit icon ( ) next to General Settings.

If a view icon ( ) appears instead, settings are inherited from an ancestor policy, or you do not have permission
to modify the settings.If the configuration is unlocked, uncheck Inherit from base policy to enable editing.

Step 3 In the Allow an Interactive Block to bypass blocking for (seconds) field, type the number of seconds that
must elapse before the user bypass expires. Specifying zero forces your users to bypass the block every time.
Step 4 Click OK.
Step 5 Click Save to save the policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1404
 CHAPTER 67
Security Intelligence Blacklisting
The following topics provide an overview of Security Intelligence, including use for blacklisting and whitelisting
traffic and basic configuration.
• About Security Intelligence, on page 1405
• Requirements for Security Intelligence, on page 1406
• Guidelines for Security Intelligence, on page 1406
• Configure Security Intelligence, on page 1407
• Troubleshooting Security Intelligence, on page 1410

About Security Intelligence

As an early line of defense against malicious internet content, Security Intelligence uses reputation intelligence
to quickly block connections to or from IP addresses, URLs, and domain names. This is called Security
Intelligence blacklisting.
Security Intelligence is an early phase of access control, before the system performs more resource-intensive
evaluation. Blacklisting improves performance by quickly excluding traffic that does not require inspection.

Note You cannot blacklist fastpathed traffic. 8000 Series fastpathing and prefilter evaluation occur before Security
Intelligence filtering. Fastpathed traffic bypasses all further evaluation, including Security Intelligence.

Although you can configure custom blacklists, Cisco provides access to regularly updated intelligence feeds.
Sites representing security threats such as malware, spam, botnets, and phishing appear and disappear faster
than you can update and deploy custom configurations.
You can refine Security Intelligence blacklisting with whitelists and monitor-only blacklists. These mechanisms
exempt traffic from being blacklisted, but do not automatically trust or fastpath matching traffic. Traffic
whitelisted or monitored at the Security Intelligence stage is intentionally subject to further analysis with the
rest of access control.
Related Topics
Security Intelligence Lists and Feeds, on page 398
Other Connections You Can Log, on page 2444
Using Connection and Security Intelligence Event Tables, on page 2483

Firepower Management Center Configuration Guide, Version 6.3

1405
 Access Control
Requirements for Security Intelligence

Requirements for Security Intelligence

If you want to whitelist, blacklist, or monitor specific IP addresses, URLs, or domain names, you must configure
custom objects, lists, or feeds. You have the following options:
• To configure network, URL, or DNS feeds, see Creating Security Intelligence Feeds, on page 403.
• To configure network, URL, or DNS lists, see Updating Security Intelligence Lists, on page 405.
• To configure network objects and object groups, see Creating Network Objects, on page 372.
• To configure URL objects and object groups, see Creating URL Objects, on page 377.

Blacklisting, whitelisting, or monitoring traffic based on a DNS list or feed also requires that you:
• Create a DNS policy. See Creating Basic DNS Policies, on page 1413 for more information.
• Configure DNS rules that reference your DNS lists or feeds. See Creating and Editing DNS Rules, on
page 1415 for more information.

Because you deploy the DNS policy as part of your access control policy, you must associate both policies.
See DNS Policy Deploy, on page 1422 for more information.

Guidelines for Security Intelligence

Security Intelligence strategies include using:
• Cisco-provided feeds—Cisco provides access to regularly updated intelligence feeds. Sites representing
security threats such as malware, spam, botnets, and phishing appear and disappear faster than you can
update and deploy custom configurations.
• Third-party feeds—Supplement Cisco-provided feeds with third-party reputation feeds, which are dynamic
lists that the Firepower Management Center downloads from the internet on a regular basis.
• Global and custom blacklists—Blacklist specific IP addresses, URLs, or domain names. To improve
performance, you may want to target enforcement, for example, restricting spam blacklisting to a security
zone that handles email traffic.
• Whitelists to eliminate false positives—When a blacklist is too broad in scope, or preemptively blocks
traffic that you want to further analyze with the rest of access control, you can override a blacklist with
a custom whitelist.
• Monitoring instead of blacklisting—Especially useful in passive deployments and for testing feeds before
you implement them; you can merely monitor and log the violating sessions instead of blocking them,
generating end-of-connection events.

Note In passive deployments, to optimize performance, we recommend that you use monitor-only settings. Managed
devices that are deployed passively cannot affect traffic flow; there is no advantage to configuring the system
to block traffic. Additionally, because blocked connections are not actually blocked in passive deployments,
the system may report multiple beginning-of-connection events for each blocked connection.

Firepower Management Center Configuration Guide, Version 6.3

1406
 Access Control
Configure Security Intelligence

Example: Whitelisting
If a reputable feed improperly blocks your access to vital resources but is overall useful to your
organization, you can whitelist only the improperly classified IP addresses, rather than removing the
whole feed from the blacklist.

Example: Security Intelligence by Zone

You can whitelist an improperly classified URL, but then restrict the whitelist object using a security
zone used by those in your organization who need to access those URLs. That way, only those with
a business need can access the whitelisted URLs. Or, you could use a third-party spam feed to blacklist
traffic on an email server security zone.

Example: Monitor-Only Blacklisting

Consider a scenario where you want to test a third-party feed before you implement blocking using
that feed. When you set the feed to monitor-only, the system allows connections that would have
been blocked to be further analyzed by the system, but also logs a record of each of those connections
for your evaluation.

Configure Security Intelligence

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

Each access control policy has Security Intelligence options. You can whitelist or blacklist network objects,
URL objects and lists, and Security Intelligence feeds and lists, all of which you can constrain by security
zone. You can also associate a DNS policy with your access control policy, and whitelist or blacklist domain
names.
The number of objects in the whitelists plus the number in the blacklists cannot exceed 255 network objects,
or 32767 URL objects and lists.

Note The system builds a separate network map for each leaf domain. In a multi-domain 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.

Before you begin

In passive deployments, or if you want to set Security Intelligence filtering to monitor-only, enable logging;
see Logging Connections with Security Intelligence, on page 2455.

Firepower Management Center Configuration Guide, Version 6.3

1407
 Access Control
Configure Security Intelligence

Procedure

Step 1 In the access control policy editor, click the Security Intelligence tab.
If the controls are dimmed, settings are inherited from an ancestor policy, or you do not have permission to
modify the configuration. If the configuration is unlocked, uncheck Inherit from base policy to enable editing.

Step 2 You have the following options:

• Click the Networks tab to add network objects.
• Click the URLs tab to add URL objects.

Step 3 Find the Available Objects you want to add to the whitelist or blacklist. You have the following options:
• Search the available objects by typing in the Search by name or value field. Clear the search string by
clicking reload ( ) or clear ( ).

• If no existing list or feed meets your needs, click the add icon ( ), select New Network List or New
URL List, and proceed as described in Creating Security Intelligence Feeds, on page 403 or Uploading
New Security Intelligence Lists to the Firepower Management Center, on page 404.

• If no existing object meets your needs, click the add icon ( ), select New Network Object or New
URL Object, and proceed as described in Creating Network Objects, on page 372.

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

Step 4 Choose one or more Available Objects to add.

Step 5 (Optional) Choose an Available Zone to constrain the selected objects by zone.
You cannot constrain system-provided Security Intelligence lists by zone.

Step 6 Click Add to Whitelist or Add to Blacklist, or click and drag the selected objects to either list.

To remove an object from a whitelist or blacklist, click its delete icon ( ) To remove multiple objects, choose
the objects and right-click to Delete Selected.

Step 7 (Optional) Set blacklisted objects to monitor-only by right-clicking the object under Blacklist, then choosing
Monitor-only (do not block).
You cannot set system-provided Security Intelligence lists to monitor only.

Step 8 Choose a DNS policy from the DNS Policy drop-down list; see DNS Policy Overview, on page 1411.
Step 9 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Security Intelligence Lists and Feeds, on page 398
Snort® Restart Scenarios, on page 311

Firepower Management Center Configuration Guide, Version 6.3

1408
 Access Control
Security Intelligence Options

Security Intelligence Options

Use the Security Intelligence tab in the access control policy editor to configure network (IP address) and
URL Security Intelligence, and to associate the access control policy with a DNS policy.

Object, Zone, and Blacklist Icons

On the Security Intelligence tab of the access control policy editor, each type of object or zone is distinguished
with an different icon.

In the blacklist, objects set to block are marked with the block icon ( ) while monitor-only objects are marked
with the monitor icon ( ). Monitor-only allows the system to handle connections involving blacklisted IP
addresses and URLs using access control, but also logs the connection’s match to the blacklist.
Because the whitelist overrides the blacklist, if you add the same object to both lists, the system displays the
blacklisted object with a strikethrough.
If configured, TID also impacts action prioritization. For more information, see TID-Firepower Management
Center Action Prioritization, on page 1610.

Zone Constraints
Except for the system-provded Global lists, you can constrain Security Intelligence filtering by zone. To
enforce Security Intelligence filtering for an object on multiple zones, you must add the object to the whitelist
or blacklist separately for each zone.

Logging
Security Intelligence logging, enabled by default, logs all blocked and monitored connections handled by an
access control policy’s target devices. However, the system does not log whitelist matches; logging of
whitelisted connections depends on their eventual disposition. You must enable logging for blacklisted
connections before you can set blacklisted objects to monitor-only.

Security Intelligence Categories

Security Intelligence Description

Category

Attacker Active scanners and blacklisted hosts known for outbound malicious activity

Bogon Bogon networks and unallocated IP addresses

Bots Sites that host binary malware droppers

CnC Sites that host command-and-control servers for botnets

Dga Malware algorithms used to generate a large number of domain names acting as
rendezvous points with their command-and-control servers

Exploitkit Software kits designed to identify software vulnerabilities in clients

Malware Sites that host malware binaries or exploit kits

OpenProxy Open proxies that allow anonymous web browsing

Firepower Management Center Configuration Guide, Version 6.3

1409
 Access Control
Troubleshooting Security Intelligence

Security Intelligence Description

Category

OpenRelay Open mail relays that are known to be used for spam

Phishing Sites that host phishing pages

Response IP addresses and URLs that are actively participating in malicious or suspicious
activity

Spam Mail hosts that are known for sending spam

Suspicious Files that appear to be suspicious and have characteristics that resemble known
malware

TorExitNode Tor exit nodes

Related Topics
Blacklist Now, Whitelist Now, and Global Lists, on page 399
Security Intelligence Lists and Multitenancy, on page 400

Troubleshooting Security Intelligence

Troubleshooting Memory Use
Symptoms: Connections that should be blacklisted by Security Intelligence are instead evaluated by access
control rules. The Security Intelligence health module alerts that it is out of memory.
Cause: Memory limitations. Cisco Intelligence Feeds are based on the latest threat intelligence from Cisco
Talos Security Intelligence and Research Group (Talos). These feeds tend to get larger as time passes. When
a Firepower device receives a feed update, it loads as many entries as it can into the memory it has allocated
for Security Intelligence. When a device cannot load all the entries, it may not block traffic as expected. Some
connections that should be blacklisted instead continue to be evaluated by access control rules.
Affected platforms: Lower-memory devices are most likely to have this issue, especially if you blacklist a
lot of Security Intelligence categories or are also filtering URLs based on category and reputation. These
devices include Firepower 7010, 7020, and 7030; ASA 5508-X, 5516-X, 5515-X, and 5525-X; NGIPSv.
Workaround: If you think this is happening, redeploy configurations to the affected devices. This can allocate
more memory to Security Intelligence. If the issue persists, contact Cisco Technical Assistance Center (TAC),
who can help you verify the issue and propose a solution appropriate to your deployment.

Firepower Management Center Configuration Guide, Version 6.3

1410
 CHAPTER 68
DNS Policies
The following topics explain DNS policies, DNS rules, and how to deploy DNS policies to managed devices.
• DNS Policy Overview, on page 1411
• DNS Policy Components, on page 1411
• DNS Rules, on page 1415
• DNS Policy Deploy, on page 1422

DNS Policy Overview

DNS-based Security Intelligence allows you to whitelist or blacklist traffic based on the domain name requested
by a client. Cisco provides domain name intelligence you can use to filter your traffic; you can also configure
custom lists and feeds of domain names tailored to your deployment.
Traffic blacklisted by a DNS policy is immediately blocked and therefore is not subject to any further
inspection—not for intrusions, exploits, malware, and so on, but also not for network discovery. You can
override blacklisting with whitelisting to force access control rule evaluation, and, recommended in passive
deployments, you can use a “monitor-only” setting for Security Intelligence filtering. This allows the system
to analyze connections that would have been blacklisted, but also logs the match to the blacklist and generates
an end-of-connection Security Intelligence event.

Note DNS-based Security Intelligence may not work as intended for a domain name unless the DNS server deletes
a domain cache entry due to expiration, or a client’s DNS cache or the local DNS server’s cache is cleared or
expires.

You configure DNS-based Security Intelligence using a DNS policy and associated DNS rules. To deploy it
to your devices, you must associate your DNS policy with an access control policy, then deploy your
configuration to managed devices.

DNS Policy Components

A DNS policy allows you to whitelist or blacklist connections based on domain name. The following list
describes the configurations you can change after creating a DNS policy.

Firepower Management Center Configuration Guide, Version 6.3

1411
 Access Control
DNS Policy Components

Name and Description

Each DNS policy must have a unique name. A description is optional.
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.
Rules
Rules provide a granular method of handling network traffic based on the domain name. Rules in a DNS
policy are numbered, starting at 1. The system matches traffic to DNS rules in top-down order by ascending
rule number.
When you create a DNS policy, the system populates it with a default Global DNS Whitelist rule and a
default Global DNS Blacklist rule. Both rules are fixed to the first position in their respective categories.
You cannot modify these rules, but you can disable them.
In a multidomain deployment, the system also adds Descendant DNS Whitelists and Descendant DNS
Blacklists rules to DNS policies in ancestor domains. These rules are fixed to the second position in their
respective categories.

Note If multitenancy is enabled for your Firepower Management Center, the system is organized into a hierarchy
of domains, including ancestor and descendant domains. These domains are distinct and separate from
the domain names used in DNS management.

A descendant list contains the domains whitelisted or blacklisted by Firepower System subdomain users.
From an ancestor domain, you cannot view the contents of descendant lists. If you do not want subdomain
users to whitelist or blacklist domains:
• disable the descendant list rules, and
• enforce Security Intelligence using the access control policy inheritance settings

The system evaluates rules in the following order:

• Global DNS Whitelist rule (if enabled)
• Descendant DNS Whitelists rule (if enabled)
• Whitelist rules
• Global DNS Blacklist rule (if enabled)
• Descendant DNS Blacklists rule (if enabled)
• Blacklist and Monitor rules

Usually, the system handles DN-based network traffic according to the first DNS rule where all the rule’s
conditions match the traffic. If no DNS rules match the traffic, the system continues evaluating the traffic
based on the associated access control policy's rules. DNS rule conditions can be simple or complex.

Firepower Management Center Configuration Guide, Version 6.3

1412
 Access Control
Creating Basic DNS Policies

Creating Basic DNS Policies

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

Procedure

Step 1 Choose Policies > Access Control > DNS.

Step 2 Click Add DNS Policy.
Step 3 Give the policy a unique Name and, optionally, a Description.
Step 4 Click Save.

What to do next
• Optionally, further configure the new policy as described in Logging Connections with Security
Intelligence, on page 2455.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Editing DNS Policies

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

Only one person should edit a DNS policy at a time, using a single browser window. If multiple users attempt
to save the same policy, only the first set of saved changes are retained.
To protect the privacy of your session, after thirty minutes of inactivity on the policy editor, a warning appears.
After sixty minutes, the system discards your changes.

Procedure

Step 1 Choose Policies > Access Control > DNS.

Step 2 Click the edit icon ( ) next to the DNS policy you want to edit.

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

Step 3 Edit your DNS policy:

Firepower Management Center Configuration Guide, Version 6.3

1413
 Access Control
Managing DNS Policies

• Name and Description—To change the name or description, click the field and type the new information.
• Rules—To add, categorize, enable, disable, or otherwise manage DNS rules, click the Rules tab and
proceed as described in Creating and Editing DNS Rules, on page 1415.

Step 4 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Managing DNS Policies

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

Use the DNS Policy page (Policies > Access Control > DNS) to manage custom DNS policies. In addition
to custom policies that you create, the system provides the Default DNS Policy, which uses the default blacklist
and whitelist. You can edit and use this system-provided custom policy. In a multidomain deployment, this
default policy uses the default Global DNS Blacklist, Global DNS Whitelist, Descendant DNS Blacklists,
and Descendant DNS Whitelists, and can only be edited in the Global domain.
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.

Procedure

Step 1 Choose Policies > Access Control > DNS.

Step 2 Manage your DNS policy:
• Compare—To compare DNS policies, click Compare Policies and proceed as described in Comparing
Policies, on page 316.
• Copy—To copy a DNS policy, click the copy icon ( ) and proceed as described in Editing DNS Policies,
on page 1413.
• Create—To create a new DNS policy, click Add DNS Policy and proceed as described in Creating Basic
DNS Policies, on page 1413.
• Delete—To delete a DNS policy, click the delete icon ( ), then confirm you want to delete the policy.
• Edit—To modify an existing DNS policy, click the edit icon ( ) and proceed as described in Editing
DNS Policies, on page 1413.

Firepower Management Center Configuration Guide, Version 6.3

1414
 Access Control
DNS Rules

DNS Rules
DNS rules handle traffic based on the domain name requested by a host. As part of Security Intelligence, this
evaluation happens after any traffic decryption, and before access control evaluation.
The system matches traffic to DNS rules in the order you specify. In most cases, the system handles network
traffic according to the first DNS rule where all the rule’s conditions match the traffic. When you create DNS
rules, the system places whitelist rules before monitor and blacklist rules, and evaluates traffic against whitelist
rules first.
In addition to its unique name, each DNS rule has the following basic components:

State
By default, rules are enabled. If you disable a rule, the system does not use it to evaluate network traffic, and
stops generating warnings and errors for that rule.

Position
Rules in a DNS policy are numbered, starting at 1. The system matches traffic to rules in top-down order by
ascending rule number. With the exception of Monitor rules, the first rule that traffic matches is the rule that
handles that traffic.

Conditions
Conditions specify the specific traffic the rule handles. A DNS rule must contain a DNS feed or list condition,
and can also match traffic by security zone, network, or VLAN.

Action
A rule’s action determines how the system handles matching traffic:
• Whitelisted traffic is allowed, subject to further access control inspection.
• Monitored traffic is subject to further evaluation by remaining DNS blacklist rules. If the traffic does
not match a DNS blacklist rule, it is inspected with access control rules. The system logs a Security
Intelligence event for the traffic.
• Blacklisted traffic is dropped without further inspection. You can also return a Domain Not Found
response, or redirect the DNS query to a sinkhole server.

Related Topics
About Security Intelligence, on page 1405

Creating and Editing DNS Rules

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

Firepower Management Center Configuration Guide, Version 6.3

1415
 Access Control
DNS Rule Management

In a DNS policy, you can add up to a total of 32767 DNS lists to the whitelist and blacklist rules; that is, the
number of lists in the DNS policy cannot exceed 32767.

Procedure

Step 1 In the DNS policy editor, you have the following options:
• To add a new rule, click Add DNS Rule.
• To edit an existing rule, click the edit icon ( ).

Step 2 Enter a Name.

Step 3 Configure the rule components, or accept the defaults:
• Action—Choose a rule Action; see DNS Rule Actions, on page 1417.
• Conditions—Configure the rule’s conditions; see DNS Rule Conditions, on page 1419.
• Enabled—Specify whether the rule is Enabled.

Step 4 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

DNS Rule Management

The Rules tab of the DNS policy editor allows you to add, edit, move, enable, disable, delete, and otherwise
manage DNS rules within your policy.
For each rule, the policy editor displays its name, a summary of its conditions, and the rule action. Other icons
represent warnings ( ), errors ( ), and other important information ( ). Disabled rules are dimmed and
marked (disabled) beneath the rule name.

Enabling and Disabling DNS Rules

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

When you create a DNS rule, it is enabled by default. If you disable a rule, the system does not use it to
evaluate network traffic and stops generating warnings and errors for that rule. When viewing the list of rules
in a DNS policy, disabled rules are dimmed, although you can still modify them. Note that you can also enable
or disable a DNS rule using the DNS rule editor.

Firepower Management Center Configuration Guide, Version 6.3

1416
 Access Control
DNS Rule Order Evaluation

Procedure

Step 1 In the DNS policy editor, right-click the rule and choose a rule state.
Step 2 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

DNS Rule Order Evaluation

Rules in a DNS policy are numbered, starting at 1. The system matches traffic to DNS rules in top-down order
by ascending rule number. In most cases, the system handles network traffic according to the first DNS rule
where all the rule’s conditions match the traffic:
• For Monitor rules, the system logs the traffic, then continues evaluating traffic against lower-priority
DNS blacklist rules.
• For non-Monitor rules, the system does not continue to evaluate traffic against additional, lower-priority
DNS rules after that traffic matches a rule.

Note the following regarding rule order:

• The Global Whitelist is always first, and takes precedence over all other rules.
• The Descendant DNS Whitelists rule only appears in multidomain deployments, in non-leaf domains. It
is always second, and takes precedence over all other rules except the Global Whitelist.
• The Whitelist section precedes the Blacklist section; whitelist rules always take precedence over other
rules.
• The Global Blacklist is always first in the Blacklist section, and takes precedence over all other Monitor
and blacklist rules.
• The Descendant DNS Blacklists rule only appears in multidomain deployments, in non-leaf domains. It
is always second in the Blacklist section, and takes precedence over all other Monitor and blacklist rules
except the Global Blacklist.
• The Blacklist section contains Monitor and blacklist rules.
• When you first create a DNS rule, the system positions it last in the Whitelist section if you assign a
Whitelist action, or last in the Blacklist section if you assign any other action.

You can drag and drop rules to reorder them.

DNS Rule Actions

Every DNS rule has an action that determines the following for matching traffic:
• handling—foremost, the rule action governs whether the system will whitelist, monitor, or blacklist
traffic that matches the rule’s conditions

Firepower Management Center Configuration Guide, Version 6.3

1417
 Access Control
DNS Rule Actions

• logging—the rule action determines when and how you can log details about matching traffic

Keep in mind that only devices deployed inline can blacklist traffic. Devices deployed passively or in tap
mode can whitelist and log, but not affect, traffic.
If configured, TID also impacts action prioritization. For more information, see TID-Firepower Management
Center Action Prioritization, on page 1610.

Whitelist Action
The Whitelist action allows matching traffic to pass. When you whitelist traffic, it is subject to further
inspection either by a matching access control rule, or the access control policy's default action.
The system does not log whitelist matches. However, logging of whitelisted connections depends on their
eventual disposition.

Monitor Action
The Monitor action does not affect traffic flow; matching traffic is neither immediately whitelisted nor
blacklisted. Rather, traffic is matched against additional rules to determine whether to permit or deny it. The
first non-Monitor DNS rule matched determines whether the system blacklists the traffic. If there are no
additional matching rules, the traffic is subject to access control evaluation.
For connections monitored by a DNS policy, the system logs end-of-connection Security Intelligence and
connection events to the Firepower Management Center database.

Blacklist Actions
The blacklist actions blacklist traffic without further inspection of any kind:
• The Drop action drops the traffic.
• The Domain Not Found action returns a non-existent internet domain response to the DNS query, which
prevents the client from resolving the DNS request.
• The Sinkhole action returns a sinkhole object's IPv4 or IPv6 address in response to the DNS query. The
sinkhole server can log, or log and block, follow-on connections to the IP address. If you configure a
Sinkhole action, you must also configure a sinkhole object.

For a connection blacklisted based on the Drop or Domain Not Found actions, the system logs
beginning-of-connection Security Intelligence and connection events. Because blacklisted traffic is immediately
denied without further inspection, there is no unique end of connection to log.
For a connection blacklisted based on the Sinkhole action, logging depends on the sinkhole object configuration.
If you configure your sinkhole object to only log sinkhole connections, the system logs end-of-connection
connection events for the follow-on connection. If you configure your sinkhole object to log and block sinkhole
connections, the system logs beginning-of-connection connection events for the follow-on connection, then
blocks that connection.

Firepower Management Center Configuration Guide, Version 6.3

1418
 Access Control
DNS Rule Conditions

Note On an ASA FirePOWER device, if you configure a DNS rule with a sinkhole action, and traffic matches the
rule, the ASA blocks the follow-on sinkhole connection by default. As a workaround, run the following
commands from the ASA command line:
asa(config)# policy-map global_policy
asa(config-pmap)# class inspection_default
asa(config-pmap-c)# no inspect dns preset_dns_map

If the ASA continues to block the connection, contact Support.

Related Topics
How Rules and Policy Actions Affect Logging, on page 2445

DNS Rule Conditions

A DNS rule’s conditions identify the type of traffic that rule handles. Conditions can be simple or complex.
You must define a DNS feed or list condition within a DNS rule. You can also optionally control traffic by
security zone, network, or VLAN.
When adding conditions to a DNS rule:
• If you do not configure a particular condition for a rule, the system does not match traffic based on that
criterion.
• You can configure multiple conditions per rule. Traffic must match all the conditions in the rule for the
rule to apply to traffic. For example, a rule with a DNS feed or list condition and network condition but
no VLAN tag condition evaluates traffic based on the domain name and source or destination, regardless
of any VLAN tagging in the session.
• For each condition in a rule, you can add up to 50 criteria. Traffic that matches any of a condition’s
criteria satisfies the condition. For example, you can use a single rule to blacklist traffic based on up to
50 DNS lists and feeds.

Controlling Traffic Based on DNS and Security Zone

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

Zone conditions in DNS rules allow you to control traffic by its source and destination security zones. A
security zone is a grouping of one or more interfaces, which may be located across multiple devices. An option
you choose during a device’s initial setup, called its detection mode, determines how the system initially
configures the device’s interfaces, and whether those interfaces belong to a security zone.

Procedure

Step 1 In the DNS rule editor, click the Zones tab.

Firepower Management Center Configuration Guide, Version 6.3

1419
 Access Control
Controlling Traffic Based on DNS and Network

Step 2 Find and select the zones you want to add from the Available Zones. To search for zones to add, click the
Search by name prompt above the Available Zones list, then type a zone name. The list updates as you type
to display matching zones.
Step 3 Click to select a zone, or right-click and then select Select All.
Step 4 Click Add to Source, or drag and drop.
Step 5 Save or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Controlling Traffic Based on DNS and Network

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

Network conditions in DNS rules allow you to control traffic by its source IP address. You can explicitly
specify the source IP addresses for the traffic you want to control.

Procedure

Step 1 In the DNS rule editor, click the Networks tab.

Step 2 Find and select the networks you want to add from the Available Networks, as follows:

• To add a network object on the fly, which you can then add to the condition, click the add icon ( )
above the Available Networks list and proceed as described in Creating Network Objects, on page 372.
• To search for network objects to add, click the Search by name or value prompt above the Available
Networks list, then type an object name or the value of one of the object’s components. The list updates
as you type to display matching objects.

Step 3 Click Add to Source, or drag and drop.

Step 4 Add any source IP addresses or address blocks that you want to specify manually. Click the Enter an IP
address prompt below the Source Networks list; then type an IP address or address block and click Add.
The system builds a separate network map for each leaf domain. In a multi-domain deployment, using literal
IP addresses to constrain this configuration can have unexpected results. Using override-enabled objects
allows descendant domain administrators to tailor Global configurations to their local environments.

Step 5 Save or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1420
 Access Control
Controlling Traffic Based on DNS and VLAN

Controlling Traffic Based on DNS and VLAN

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

VLAN conditions in DNS rules allow you to control VLAN-tagged traffic. The system uses the innermost
VLAN tag to identify a packet by VLAN.
When you build a VLAN-based DNS rule condition, you can manually specify VLAN tags. Alternately, you
can configure VLAN conditions with VLAN tag objects, which are reusable and associate a name with one
or more VLAN tags.

Procedure

Step 1 In the DNS rule editor, select the VLAN Tags tab.
Step 2 Find and select the VLANs you want to add from the Available VLAN Tags, as follows:

• To add a VLAN tag object on the fly, which you can then add to the condition, click the add icon ( )
above the Available VLAN Tags list and proceed as described in Creating VLAN Tag Objects, on page
375.
• To search for VLAN tag objects and groups to add, click the Search by name or value prompt above
the Available VLAN Tags list, then type either the name of the object, or the value of a VLAN tag in
the object. The list updates as you type to display matching objects.

Step 3 Click Add to Rule, or drag and drop.

Step 4 Add any VLAN tags that you want to specify manually. Click the Enter a VLAN Tag prompt below the
Selected VLAN Tags list; then type a VLAN tag or range and click Add. You can specify any VLAN tag
from 1 to 4094; use a hyphen to specify a range of VLAN tags.
The system builds a separate network map for each leaf domain. In a multidomain deployment, using literal
VLAN tags to constrain this configuration can have unexpected results. Using override-enabled objects allows
descendant domain administrators to tailor Global configurations to their local environments.

Step 5 Save or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1421
 Access Control
Controlling Traffic Based on DNS List, Feed, or Category

Controlling Traffic Based on DNS List, Feed, or Category

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Any Any Admin/Access

Admin/Network
Admin

DNS conditions in DNS rules allow you to control traffic if a DNS list, feed, or category contains the domain
name requested by the client. You must define a DNS condition in a DNS rule.
Regardless of whether you add a global or custom whitelist or blacklist to a DNS condition, the system applies
the configured rule action to the traffic. For example, if you add the Global Whitelist to a rule, and configure
a Drop action, the system blacklists all traffic that should have been whitelisted.

Procedure

Step 1 In the DNS rule editor, click the DNS tab.

Step 2 Find and select the DNS lists and feeds you want to add from the DNS Lists and Feeds, as follows:

• To add a DNS list or feed on the fly, which you can then add to the condition, click the add icon ( )
above the DNS Lists and Feeds list and proceed as described in Creating Security Intelligence Feeds,
on page 403 .
• To search for DNS lists, feeds, or categories to add, click the Search by name or value prompt above
the DNS Lists and Feeds list, then type an object name or the value of one of the object’s components.
The list updates as you type to display matching objects.

Step 3 Click Add to Rule, or drag and drop.

Step 4 Save or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

DNS Policy Deploy

Smart License Classic License Supported Devices Supported Domains

Threat Protection Any Any

After you finish updating your DNS policy configuration, you must deploy it as part of access control
configuration.
• Associate your DNS policy with an access control policy, as described in Configure Security Intelligence,
on page 1407.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1422
 CHAPTER 69
Prefiltering and Prefilter Policies
The following topics describe how to configure prefiltering:
• About Prefiltering, on page 1423
• Guidelines and Limitations for Prefiltering, on page 1426
• Configure Prefiltering, on page 1426
• Tunnel Zones and Prefiltering, on page 1431

About Prefiltering
Prefiltering is the first phase of access control, before the system performs more resource-intensive evaluation.
Prefiltering is simple, fast, and early. Prefiltering uses limited outer-header criteria to quickly handle traffic.
Compare this to subsequent evaluation, which uses inner headers and has more robust inspection capabilities.
Configure prefiltering to:
• Improve performance— The sooner you exclude traffic that does not require inspection, the better. You
can fastpath or block certain types of plaintext, passthrough tunnels based on their outer encapsulation
headers, without inspecting their encapsulated connections. You can also fastpath or block any other
connections that benefit from early handling.
• Tailor deep inspection to encapsulated traffic—You can rezone certain types of tunnels, so that you can
later handle their encapsulated connections using the same inspection criteria. Rezoning is necessary
because after prefiltering, access control uses inner headers.

Prefiltering vs Access Control

Prefilter and access control policies both allow you to block and trust traffic, though the prefiltering "trust"
functionality is called "fastpathing" because it skips more inspection. The following table explains this and
other differences between prefiltering and access control, to help you decide whether to configure custom
prefiltering.
If you do not configure custom prefiltering, you can only approximate—not replicate—prefilter functionality
with early-placed Block and Trust rules in the access control policy.

Firepower Management Center Configuration Guide, Version 6.3

1423
 Access Control
Prefiltering vs Access Control

Characteristic Prefiltering Access Control For more information, see...

Primary function Quickly fastpath or block certain Inspect and control all network About Prefiltering, on page 1423
types of plaintext, passthrough traffic, using simple or complex
tunnels (see Encapsulation criteria, including contextual
Conditions, on page 334), or tailor information and deep inspection
subsequent inspection to their results.
encapsulated traffic.
Fastpath or block any other
connections that benefit from early
handling.

Implementation Prefilter policy. Access control policy. About Prefilter Policies, on page 1428
The prefilter policy is invoked by The access control policy is a Associating Other Policies with
the access control policy. master configuration. In addition Access Control, on page 1365
to invoking subpolicies, access
control policies have their own
rules.

Sequence within First. — —

access control
The system matches traffic to
prefilter criteria before all other
access control configurations.

Rule actions Fewer. More. Tunnel and Prefilter Rule

Components, on page 1429
You can stop further inspection Access control rules have a larger
(Fastpath and Block) or allow variety of actions, including Access Control Rule Actions, on
further analysis with the rest of monitoring, deep inspection, block page 1376
access control (Analyze). with reset, and interactive blocking.

Bypass capability Fastpath rule action. Trust rule action. Introduction to Access Control
Rules, on page 1367
Fastpathing traffic in the prefilter Traffic trusted by access control
stage bypasses all further inspection rules is only exempt from deep
and handling, including: inspection and discovery.
• Security Intelligence
• authentication requirements
imposed by an identity policy
• SSL decryption
• access control rules
• deep inspection of packet
payloads
• discovery
• rate limiting

Firepower Management Center Configuration Guide, Version 6.3

1424
 Access Control
Passthrough Tunnels and Access Control

Characteristic Prefiltering Access Control For more information, see...

Rule criteria Limited. Robust. Tunnel vs Prefilter Rules, on page

1428
Rules in the prefilter policy use Access control rules use network
simple network criteria: IP address, criteria, but also user, application, Rule Condition Types, on page 323
VLAN tag, port, and protocol. requested URL, and other
contextual information available in
For tunnels, tunnel endpoint
packet payloads.
conditions specify the IP address of
the routed interfaces of the network Network conditions specify the IP
devices on either side of the tunnel. address of source and destination
hosts.

IP headers used Outermost. Innermost possible. Passthrough Tunnels and Access

(tunnel handling) Control, on page 1425
Using outer headers allows you to For a nonencrypted tunnel, access
handle entire plaintext, passthrough control acts on its individual
tunnels. encapsulated connections, not the
tunnel as a whole.
For nonencapsulated traffic,
prefiltering still uses "outer"
headers—which in this case are the
only headers.

Rezone encapsulated Rezones tunneled traffic. Uses tunnel zones. Tunnel Zones and Prefiltering, on
connections for page 1431
Tunnel zones allow you to tailor Access control uses the tunnel
further analysis
subsequent inspection to prefiltered, zones you assign during
encapsulated traffic. prefiltering.

Connection logging Fastpathed and blocked traffic only. Any connection. Other Connections You Can Log,
Allowed connections may still be on page 2444
logged by other configurations.

Supported devices Firepower Threat Defense only. All. Guidelines and Limitations for
Prefiltering, on page 1426

Passthrough Tunnels and Access Control

Plaintext (nonencrypted) tunnels can encapsulate multiple connections, often flowing between discontinuous
networks. These tunnels are especially useful for routing custom protocols over IP networks, IPv6 traffic over
IPv4 networks, and so on.
An outer encapsulation header specifies the source and destination IP addresses of the tunnel endpoints—the
routed interfaces of the network devices on either side of the tunnel. Inner payload headers specify the source
and destination IP addresses of the encapsulated connections' actual endpoints.
Often, network security devices handle plaintext tunnels as passthrough traffic. That is, the device is not one
of the tunnel endpoints. Instead, it is deployed between the tunnel endpoints and monitors the traffic flowing
between them.

Firepower Management Center Configuration Guide, Version 6.3

1425
 Access Control
Guidelines and Limitations for Prefiltering

Some network security devices, such as Cisco ASA firewalls running Cisco ASA Software (rather than
Firepower Threat Defense), enforce security policies using outer IP headers. Even for plaintext tunnels, these
devices have no control over or insight into individual encapsulated connections and their payloads.
By contrast, the Firepower System leverages access control as follows:
• Outer header evaluation—First, prefiltering uses outer headers to handle traffic. You can block or fastpath
entire plaintext, passthrough tunnels at this stage.
• Inner header evaluation—Next, the rest of access control (and other features such as QoS) use the
innermost detectable level of headers to ensure the most granular level of inspection and handling possible.
If a passthrough tunnel is not encrypted, the system acts on its individual encapsulated connections at
this stage. You must rezone a tunnel (see Tunnel Zones and Prefiltering, on page 1431) to act on all its
encapsulated connections.

Access control has no insight into encrypted passthrough tunnels. For example, access control rules see a
passthrough VPN tunnel as one connection. The system handles the entire tunnel using only the information
in its outer, encapsulation header.

Guidelines and Limitations for Prefiltering

Model Requirements
Prefiltering is supported on Firepower Threat Defense devices only. Prefilter configurations have no effect
on other devices.

Prefilter-like Capabilities on Other Devices

For Classic devices (7000/8000 series, ASA FirePOWER, NGIPSv):
• Use early-placed Trust and Block access control rules to approximate prefilter functionality, keeping in
mind the differences between the two features. See Prefiltering vs Access Control, on page 1423.
• Match entire GRE-encapsulated tunnels using access control rules, with some limitations. See Port and
ICMP Code Conditions, on page 332.

• (8000 series only) Device-specific fastpath rules can bypass access control, but cannot block traffic. See
Configuring Fastpath Rules (8000 Series), on page 511.

Configure Prefiltering
Smart License Classic License Supported Devices Supported Domains Access
Any N/A FTD Any Admin/Access
Admin/Network
Admin

To perform custom prefiltering, configure and deploy prefilter policies to managed devices, as a part of access
control.

Firepower Management Center Configuration Guide, Version 6.3

1426
Access Control
Configure Prefiltering

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.

Procedure

Step 1 Choose Policies > Access Control > Prefilter.

Step 2 Click New Policy to create a custom prefilter policy.
A new prefilter policy has no rules and a default action of Analyze all tunnel traffic. It performs no logging
or tunnel rezoning. You can also copy ( ) or edit ( ) an existing policy.

Step 3 Configure the prefilter policy's default action and its logging options.
• Default action—Choose a default action for supported plaintext, passthrough tunnels: Analyze all tunnel
traffic (with access control) or Block all tunnel traffic.
• Default action logging—Click the logging icon ( ) next to the default action; see Logging Connections
with a Policy Default Action, on page 2457. You can configure default action logging for blocked tunnels
only.

Step 4 Configure tunnel and prefilter rules.

In a custom prefilter policy, you can use both kinds of rule, in any order. Create rules depending on the specific
type of traffic you want to match and the actions or further analysis you want to perform; see Tunnel vs
Prefilter Rules, on page 1428.
Caution Exercise caution when using tunnel rules to assign tunnel zones. Connections in rezoned tunnels
may not match security zone constraints in later evaluation. For more information, see Tunnel Zones
and Prefiltering, on page 1431.

For detailed information on configuring rule components, see Tunnel and Prefilter Rule Components, on page
1429 and Rule Management: Common Characteristics, on page 321.

Step 5 Evaluate rule order. To move a rule, click and drag or use the right-click menu to cut and paste.
Properly creating and ordering rules is a complex task, but one that is essential to building an effective
deployment. If you do not plan carefully, rules can preempt other rules or contain invalid configurations. For
more information, see Rule Performance Guidelines, on page 352.

Step 6 Save the prefilter policy.

Step 7 For configurations that support tunnel zone constraints, appropriately handle rezoned tunnels.
Match connections in rezoned tunnels by using tunnel zones as source zone constraints; see Configuring
Interface Conditions, on page 327.
Step 8 Associate the prefilter policy with the access control policy deployed to your managed devices.
See Associating Other Policies with Access Control, on page 1365.

Step 9 Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1427
 Access Control
About Prefilter Policies

About Prefilter Policies

Prefiltering is a policy-based feature. In the Firepower System, an access control policy is a master configuration
that invokes subpolicies and other configurations, including a prefilter policy.

Policy Components: Rules and Default Action

In a prefilter policy, tunnel rules, prefilter rules, and a default action handle network traffic:
• Tunnel and prefilter rules—First, rules in a prefilter policy handle traffic in the order you specify. Tunnel
rules match specific tunnels only and support rezoning. Prefilter rules have a wider range of constraints
and do not support rezoning. For more information, see Tunnel vs Prefilter Rules, on page 1428.
• Default action (tunnels only)—If a tunnel does not match any rules, the default action handles it. The
default action can block these tunnels, or continue access control on their individual encapsulated
connections. You cannot rezone tunnels with the default action.
There is no default action for nonencapsulated traffic. If a nonencapsulated connection does not match
any prefilter rules, the system continues with access control.

Connection Logging
You can log connections fastpathed and blocked by the prefilter policy; see Other Connections You Can Log,
on page 2444.
Connection events contain information on whether and how logged connections—including entire tunnels—were
prefiltered. You can view this information in event views (workflows), dashboards, and reports, and use it as
correlation criteria. Keep in mind that because fastpathed and blocked connections are not subject to deep
inspection, associated connection events contain limited information.

Default Prefilter Policy

Every access control policy has an associated prefilter policy.
The system uses a default policy if you do not configure custom prefiltering. Initially, this system-provided
policy passes all traffic to the next phase of access control. You can change the policy's default action and
configure its logging options, but you cannot add rules to it or delete it.

Prefilter Policy Inheritance and Multitenancy

Access control uses a hierarchical implementation that complements multitenancy. Along with other advanced
settings, you can lock a prefilter policy association, enforcing that association in all descendant access control
policies. For more information, see Access Control Policy Inheritance, on page 1353.
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. The default prefilter policy belongs to the Global domain.

Tunnel vs Prefilter Rules

Whether you configure a tunnel or prefilter rule depends on the specific type of traffic you want to match and
the actions or further analysis you want to perform.

Firepower Management Center Configuration Guide, Version 6.3

1428
 Access Control
Tunnel and Prefilter Rule Components

Characteristic Tunnel Rules Prefilter Rules

Primary function Quickly fastpath, block, or rezone plaintext, Quickly fastpath or block any other
passthough tunnels. connection that benefits from early
handling.

Encapsulation and Encapsulation conditions match only Port conditions can use a wider range of
port/protocol criteria plaintext tunnels over selected protocols, port and protocol constraints than tunnel
listed in Encapsulation Conditions, on page rules; see Port and ICMP Code Conditions,
334. on page 332.

Network criteria Tunnel endpoint conditions constrain the Network conditions constrain the source
endpoints of the tunnels you want to and destination hosts in each connection;
handle; see Tunnel Endpoint Conditions, see Network Conditions, on page 328.
on page 330.

Direction Bidirectional or unidirectional Unidirectional only (nonconfigurable).

(configurable).
Prefilter rules match source-to-destination
Tunnel rules are bidirectional by default, traffic only.
so they can handle all traffic between
tunnel endpoints.

Rezone sessions for Supported, using tunnel zones; see Tunnel Not supported.
further analysis Zones and Prefiltering, on page 1431.

Tunnel and Prefilter 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.

Position
Rules are numbered, starting at 1. The system matches traffic to rules in top-down order by ascending rule
number. The first rule that traffic matches is the rule that handles that traffic, regardless of rule type (tunnel
vs prefilter).

Action
A rule's action determines how the system handles and logs matching traffic:
• Fastpath—Exempts matching traffic from all futher inspection and control, including access control,
identity requirements, and rate limiting. Fastpathing a tunnel fastpaths all encapsulated connections.
• Block—Blocks matching traffic without further inspection of any kind. Blocking a tunnel blocks all
encapsulated connections.
• Analyze—Allows traffic to continue to be analyzed by the rest of access control, using inner headers. If
passed by access control and any related deep inspection, this traffic may also be rate limited. For tunnel
rules, enables rezoning with the Assign Tunnel Zone option.

Firepower Management Center Configuration Guide, Version 6.3

1429
 Access Control
Tunnel and Prefilter Rule Components

Direction (Tunnel Rules Only)

A tunnel rule's direction determines how the system source and destination criteria:
• Match tunnels only from source (unidirectional)—Match source-to-destination traffic only. Matching
traffic must originate from one of the specified source interfaces or tunnel endpoints, and leave through
one of the destination interfaces or tunnel endpoints.
• Match tunnels from source and destination (bidirectional)—Match both source-to-destination traffic and
destination-to-source traffic. The effect is identical to writing two unidirectional rules, one the mirror of
the other.

Prefilter rules are always unidirectional.

Assign Tunnel Zone (Tunnel Rules Only)

In a tunnel rule, assigning a tunnel zone (whether existing or created on the fly), rezones matching tunnels.
Rezoning requires the Analyze action.
Rezoning a tunnel allows other configurations—such as access control rules—to recognize all the tunnel's
encapsulated connections as belonging together. By using a tunnel's assigned tunnel zone as an interface
constraint, you can tailor inspection to its encapsulated connections. For more information, see Tunnel Zones
and Prefiltering, on page 1431.

Caution Exercise caution when assigning tunnel zones. Connections in rezoned tunnels may not match security zone
constraints in later evaluation. See Using Tunnel Zones, on page 1431 for a brief walkthrough of a tunnel zone
implementation, and a discussion of the implications of rezoning without explicitly handling rezoned traffic.

Conditions
Conditions specify the specific traffic the rule handles. Traffic must match all a rule's conditions to match the
rule. Each condition type has its own tab in the rule editor.
You can prefilter traffic using the following outer-header constraints:
• Interface—Interface Conditions, on page 325
• Network—Tunnel Endpoint Conditions, on page 330 or Network Conditions, on page 328
• Port—Encapsulation Conditions, on page 334 or Port and ICMP Code Conditions, on page 332
• VLAN—VLAN Conditions, on page 331

You must constrain tunnel rules by encapsulation protocol.

Logging
A rule's logging settings govern the records the system keeps of the traffic it handles.
In tunnel and prefilter rules, you can log fastpathed and blocked traffic (the Fastpath and Block actions). For
traffic subject to further analysis (the Analyze action), logging in the prefilter policy is disabled, although
matching connections may still be logged by other configurations. For more information, see Logging
Connections with Tunnel and Prefilter Rules, on page 2454.

Firepower Management Center Configuration Guide, Version 6.3

1430
 Access Control
Tunnel Zones and Prefiltering

Comments
Each time you save changes to a rule you can add comments. For example, you might summarize the overall
configuration for the benefit of other users, or note when you change a rule and the reason for the change.
You cannot edit or delete these comments after you save the rule.
Related Topics
Rule Performance Guidelines, on page 352

Tunnel Zones and Prefiltering

Tunnel zones allow you to use prefiltering to tailor subsequent traffic handling to encapsulated connections.
A special mechanism is required because usually, the system handles traffic using the innermost detectable
level of headers. This ensures the most granular level of inspection possible. But it also means that if a
passthrough tunnel is not encrypted, the system acts on its individual encapsulated connections; see Passthrough
Tunnels and Access Control, on page 1425.
Tunnel zones solve this problem. During the first phase of access control (prefiltering) you can use outer
headers to identify certain types of plaintext, pasthrough tunnels. Then, you can rezone those tunnels by
assigning a custom tunnel zone.
Rezoning a tunnel allows other configurations—such as access control rules—to recognize all the tunnel's
encapsulated connections as belonging together. By using a tunnel's assigned tunnel zone as an interface
constraint, you can tailor inspection to its encapsulated connections.
Despite its name, a tunnel zone is not a security zone. A tunnel zone does not represent a set of interfaces. It
is more accurate to think of a tunnel zone as a tag that, in some cases, replaces the security zone associated
with an encapsulated connection.

Caution For configurations that support tunnel zone constraints, connections in rezoned tunnels do not match security
zone constraints. For example, after you rezone a tunnel, access control rules can match its encapsulated
connections with their newly assigned tunnel zone, but not with any original security zone.

See Using Tunnel Zones, on page 1431 for a brief walkthough of a tunnel zone implementation, and a discussion
of the implications of rezoning without explicitly handling rezoned traffic.

Configurations Supporting Tunnel Zone Constraints

Only access control rules support tunnel zone constraints.
No other configurations support tunnel zone constraints. For example, you cannot use QoS to rate limit a
plaintext tunnel as a whole; you can only rate limit its individual encapsulated sessions.

Using Tunnel Zones

Smart License Classic License Supported Devices Supported Domains Access

Any Any FTD Any Admin/Access

Admin/Network
Admin

Firepower Management Center Configuration Guide, Version 6.3

1431
 Access Control
Using Tunnel Zones

This example procedure summarizes how you might rezone GRE tunnels for further analysis, using tunnel
zones. You can adapt the concepts described in this example to other scenarios where you need to tailor traffic
inspection to connections encapsulated in plaintext, passthrough tunnels.
Consider a Firepower System deployment where your organization's internal traffic flows through the Trusted
security zone. The Trusted security zone represents a set of sensing interfaces across multiple managed devices
deployed in various locations. Your organization's security policy requires that you allow internal traffic after
deep inspection for exploits and malware.
Internal traffic sometimes includes plaintext, passthrough, GRE tunnels between particular endpoints. Because
the traffic profile of this encapsulated traffic is different from your "normal" interoffice activity—perhaps it
is known and benign—you can limit inspection of certain encapsulated connections while still complying
with your security policy.
In this example, after you deploy configuration changes:
• Plaintext, passthrough, GRE-encapsulated tunnels detected in the Trusted zone have their individual
encapsulated connections evaluated by one set of intrusion and file policies.
• All other traffic in the Trusted zone is evaluated with a different set of intrusion and file policies.

You accomplish this task by rezoning GRE tunnels. Rezoning ensures that access control associates
GRE-encapsulated connections with a custom tunnel zone, rather than their original Trusted security zone.
Rezoning is required due to the way the Firepower System and access control handle encapsulated traffic; see
Passthrough Tunnels and Access Control, on page 1425 and Tunnel Zones and Prefiltering, on page 1431.

Procedure

Step 1 Configure custom intrusion and file policies that tailor deep inspection to encapsulated traffic, and another
set of intrusion and file policies tailored to nonencapsulated traffic.
Step 2 Configure custom prefiltering to rezone GRE tunnels flowing through the Trusted security zone.
Create a custom prefilter policy and associate it with access control. In that custom prefilter policy, create a
tunnel rule (in this example, GRE_tunnel_rezone) and a corresponding tunnel zone (GRE_tunnel).
For more information, see Configure Prefiltering, on page 1426.

Table 92: GRE_tunnel_rezone Tunnel Rule

Rule Component Description

Interface object condition Match internal-only tunnels by using the Trusted security zone as both a Source
Interface Object and Destination Interface Object constraint.

Tunnel endpoint condition Specify the source and destination endpoints for the GRE tunnels used in your
organization.
Tunnel rules are bidirectional by default. If you do not change the Match tunnels
from... option, it does not matter which endpoints you specify as source and
which as destination.

Encapsulation condition Match GRE traffic.

Assign Tunnel Zone Create the GRE_tunnel tunnel zone, and assign it to tunnels that match the
rule.

Firepower Management Center Configuration Guide, Version 6.3

1432
Access Control
Using Tunnel Zones

Rule Component Description

Action Analyze (with the rest of access control).

Step 3 Configure access control to handle connections in rezoned tunnels.

In the access control policy deployed to your managed devices, configure a rule (in this example,
GRE_inspection) that handles the traffic you rezoned. For more information, see Creating and Editing
Access Control Rules, on page 1374.

Table 93: GRE_inspection Access Control Rule

Rule Component Description

Security zone condition Match rezoned tunnels by using the GRE_tunnel security zone as a Source Zone
constraint; see Interface Conditions, on page 325.

Action Allow, with deep inspection enabled.

Choose the file and intrusion policies tailored to inspect encapsulated internal
traffic.

Caution If you skip this step, the rezoned connections may match any access control rule not constrained
by security zone. If the rezoned connections do not match any access control rules, they are handled
by the access control policy default action. Make sure this is your intent.

Step 4 Configure access control to handle nonencapsulated connections flowing through the Trusted security zone.
In the same access control policy, configure a rule (in this example, internal_default_inspection)
that handles non-rezoned traffic in the Trusted security zone.

Table 94: internal_default_inspection Access Control Rule

Rule Component Description

Security zone condition Match non-rezoned internal-only traffic by using the Trusted security zone as
both a Source Zone and Destination Zone constraint.

Action Allow, with deep inspection enabled.

Choose the file and intrusion policies tailored to inspect nonencapsulated internal
traffic.

Step 5 Evaluate the position of the new access control rules relative to preexisting rules. Change rule order if necessary.
If you place the two new access control rules next to each other, it does not matter which you place first.
Because you rezoned GRE tunnels, the two rules cannot preempt each other.

Step 6 Save all changed configurations.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1433
 Access Control
Creating Tunnel Zones

Creating Tunnel Zones

Smart License Classic License Supported Devices Supported Domains Access

Any N/A Firepower Threat Any Admin/Access

Defense Admin/Network
Admin

Procedure

Step 1 Choose Objects > Object Management.

Step 2 Chose Tunnel Zone from the list of object types.
Step 3 Click Add Tunnel Zone.
Step 4 Enter a Name and, optionally, a Description.
Step 5 Click Save.

What to do next
• Assign tunnel zones to plaintext, passthrough tunnels as part of custom prefiltering; see Configure
Prefiltering, on page 1426.

Firepower Management Center Configuration Guide, Version 6.3

1434
 CHAPTER 70
Intelligent Application Bypass
The following topics describe how to configure access control polices to use Intelligent Application Bypass
(IAB)
• Introduction to IAB, on page 1435
• IAB Options, on page 1436
• Configuring IAB, on page 1438
• IAB Logging and Analysis, on page 1439

Introduction to IAB
IAB identifies applications that you trust to traverse your network without further inspection if performance
and flow thresholds are exceeded. For example, if a nightly backup significantly impacts system performance,
you can configure thresholds that, if exceeded, trust traffic generated by your backup application. Optionally,
you can configure IAB so that, when an inspection performance threshold is exceeded, IAB trusts all traffic
that exceeds any flow bypass threshold, regardless of the application type.
The system implements IAB on traffic allowed by access control rules or the access control policy's default
action, before the traffic is subject to deep inspection. A test mode allows you to determine whether thresholds
are exceeded and, if so, to identify the application flows that would have been bypassed if you had actually
enabled IAB (called bypass mode).
The following graphic illustrates the IAB decision-making process:

Firepower Management Center Configuration Guide, Version 6.3

1435
 Access Control
IAB Options

IAB Options
State
Enables or disables IAB.

Performance Sample Interval

Specifies the time in seconds between IAB performance sampling scans, during which the system collects
system performance metrics for comparison to IAB performance thresholds. A value of 0 disables IAB.

Bypassable Applications and Filters

This feature provides two mutually exclusive options:

Firepower Management Center Configuration Guide, Version 6.3

1436
Access Control
IAB Options

Applications/Filters
Provides an editor where you can specify bypassable applications and sets of applications (filters). See
Application Conditions (Application Control), on page 334.
All applications including unidentified applications
When an inspection performance threshold is exceeded, trusts all traffic that exceeds any flow bypass
threshold, regardless of the application type.

Performance and Flow Thresholds

You must configure at least one inspection performance threshold and one flow bypass threshold. When a
performance threshold is exceeded, the system examines flow thresholds and, if one threshold is exceeded,
trusts the specified traffic.If you enable more than one of either, only one of each must be exceeded.
Inspection performance thresholds provide intrusion inspection performance limits that, if exceeded, trigger
the inspection of flow thresholds. IAB does not use inspection performance thresholds set to 0. You can
configure one or more of the following inspection performance thresholds:
Drop Percentage
Average packets dropped as a percentage of total packets, when packets are dropped because of
performance overloads caused by expensive intrusion rules, file policies, decompression, and so on. This
does not refer to packets dropped by normal configurations such as intrusion rules. Note that specifying
an integer greater than 1 activates IAB when the specified percentage of packets is dropped. When you
specify 1, any percentage from 0 through 1 activates IAB. This allows a small number of packets to
activate IAB.
Processor Utilization Percentage
Average percentage of processor resources used.
Package Latency
Average packet latency in microseconds.
Flow Rate
The rate at which the system processes flows, measured as the number of flows per second. Note that
this option configures IAB to measure flow rate, not flow count.
Flow bypass thresholds provide flow limits that, if exceeded, trigger IAB to trust bypassable application
traffic in bypass mode or allow application traffic subject to further inspection in test mode. IAB does not use
flow bypass thresholds set to 0. You can configure one or more of the following flow bypass thresholds:
Bytes per Flow
The maximum number of kilobytes a flow can include.
Packets per Flow
The maximum number of packets a flow can include.
Flow Duration
The maximum number of seconds a flow can remain open.
Flow Velocity
The maximum transfer rate in kilobytes per second.

Firepower Management Center Configuration Guide, Version 6.3

1437
 Access Control
Configuring IAB

Configuring IAB
Smart License Classic License Supported Devices Supported Domains Access

Any Control Any Any Admin

Access Admin
Network Admin

Caution Not all deployments require IAB, and those that do might use it in a limited fashion. Do not enable IAB unless
you have expert knowledge of your network traffic, especially application traffic, and system performance,
including the causes of predictable performance issues. Before you run IAB in bypass mode, make sure that
trusting the specified traffic does not expose you to risk.

Procedure

Step 1 In the access control policy editor, click the Advanced tab, then click the edit icon ( ) next to Intelligent
Application Bypass Settings.

If a view icon ( ) 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 2 Configure IAB options:

• State—Turn IAB Off or On, or enable IAB in Test mode.
• Performance Sample Interval—Enter the time in seconds between IAB performance-sampling scans. If
you enable IAB, even in test mode, enter a non-zero value. Entering 0 disables IAB.
• Bypassable Applications and Filters—Choose from:
• Click the number of bypassed applications and filters and specify the applications whose traffic you
want to bypass; see Configuring Application Conditions and Filters, on page 336.
• Click All applications including unidentified applications so that, when an inspection performance
threshold is exceeded, IAB trusts all traffic that exceeds any flow bypass threshold, regardless of
the application type.

• Inspection Performance Thresholds—Click Configure and enter at least one threshold value.
• Flow Bypass Thresholds—Click Configure and enter at least one threshold value.
You must specify at least one inspection performance threshold and one flow bypass threshold; both must be
exceeded for IAB to trust traffic. If you enter more than one threshold of each type, only one of each type
must be exceeded. For detailed information, see IAB Options, on page 1436.

Step 3 Click OK to save IAB settings.

Step 4 Click Save to save the policy.

Firepower Management Center Configuration Guide, Version 6.3

1438
 Access Control
IAB Logging and Analysis

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

IAB Logging and Analysis

IAB forces an end-of-connection event that logs bypassed flows and flows that would have been bypassed,
regardless of whether you have enabled connection logging. Connection events indicate flows that are bypassed
in bypass mode or that would have been bypassed in test mode. Custom dashboard widgets and reports based
on connection events can display long-term statistics for bypassed and would-have-bypassed flows.

IAB Connection Events

Action
When Reason includes Intelligent App Bypass:

Allow -
indicates that the applied IAB configuration was in test mode and traffic for the application specified
by Application Protocol remains available for inspection.
Trust -
indicates that the applied IAB configuration was in bypass mode and traffic for the application
specified by Application Protocol has been trusted to traverse the network without further inspection.
Reason
Intelligent App Bypass indicates that IAB triggered the event in bypass or test mode.
Application Protocol
This field displays the application protocol that triggered the event.

Example
In the following truncated graphic, some fields are omitted. The graphic shows the Action, Reason,
and Application Protocol fields for two connection events resulting from different IAB settings in
two separate access control policies.
For the first event, the Trust action indicates that IAB was enabled in bypass mode and Bonjour
protocol traffic was trusted to pass without further inspection.
For the second event, the Allow action indicates that IAB was enabled in test mode, so Ubuntu Update
Manager traffic was subject to further inspection but would have been bypassed if IAB had been in
bypass mode.

Firepower Management Center Configuration Guide, Version 6.3

1439
 Access Control
IAB Logging and Analysis

Example
In the following truncated graphic, some fields are omitted. The flow in the second event was both
bypassed (Action: Trust; Reason: Intelligent App Bypass) and inspected by an intrusion rule
(Reason: Intrusion Monitor). The Intrusion Monitor reason indicates that an intrusion rule set
to Generate Events detected but did not block an exploit during the connection. In the example, this
happened before the application was detected. After the application was detected, IAB recognized
the application as bypassable and trusted the flow.

IAB Custom Dashboard Widgets

You can create a Custom Analysis dashboard widget to display long-term IAB statistics based on connection
events. Specify the following when creating the widget:
• Preset: None
• Table: Application Statistics

• Field: any
• Aggregate: either of:
• IAB Bypassed Connections

• IAB Would Bypass Connections

• Filter: any

Examples
In the following Custom Analysis dashboard widget examples:
• The Bypassed example shows statistics for application traffic bypassed because the applications
were specified as bypassable and IAB was enabled in bypass mode in the deployed access
control policy.
• The Would Have Bypassed example shows statistics for application traffic that would have been
bypassed because the applications were specified as bypassable and IAB was enabled in test
mode in the deployed access control policy. .

Firepower Management Center Configuration Guide, Version 6.3

1440
Access Control
IAB Logging and Analysis

IAB Custom Reports

You can create a custom report to display long-term IAB statistics based on connection events. Specify the
following when creating the report:
• Table: Application Statistics

• Preset: None
• Filter: any
• X-Axis: any
• Y-Axis: either of:
• IAB Bypassed Connections

• IAB Would Bypass Connections

Examples
The following graphic shows two abbreviated report examples:
• The Bypassed example shows statistics for application traffic bypassed because the applications
were specified as bypassable and IAB was enabled in bypass mode in the deployed access
control policy.
• The Would Have Bypassed example shows statistics for application traffic that would have been
bypassed because the applications were specified as bypassable and IAB was enabled in test
mode in the deployed access control policy.

Firepower Management Center Configuration Guide, Version 6.3

1441
 Access Control
IAB Logging and Analysis

Related Topics
Connection and Security Intelligence Event Fields, on page 2463
The Custom Analysis Widget, on page 222
Adding Widgets to a Dashboard, on page 232
Report Templates, on page 2257

Firepower Management Center Configuration Guide, Version 6.3

1442
 CHAPTER 71
Access Control Using Content Restriction
The following topics describe how to configure access control policies to use content restriction features:
• About Content Restriction, on page 1443
• Using Access Control Rules to Enforce Content Restriction, on page 1444
• Using a DNS Sinkhole to Enforce Content Restriction, on page 1446

About Content Restriction

Major search engines and content delivery services provide features that allow you to restrict search results
and website content. For example, schools use content restriction features to comply with the Children's
Internet Protection Act (CIPA).
When implemented by search engines and content delivery services, you can enforce content restriction
features only for individual browsers or users. The Firepower System allows you to extend these features to
your entire network.
The system allows you to enforce:
• Safe Search—Supported in many major search engines, this service filters out explicit and adult-oriented
content that business, government, and education environments classify as objectionable. The system
does not restrict a user's ability to access the home pages for supported search engines.
• YouTube EDU—This service filters YouTube content for an educational environment. It allows schools
to set access for educational content while limiting access to noneducational content. YouTube EDU is
a different feature than YouTube Restricted Mode, which enforces restrictions on YouTube searches as
part of Google's Safe Search feature. YouTube Restricted Mode is a subfeature of Safe Search. With
YouTube EDU, users access the YouTube EDU home page, rather than the standard YouTube home
page.

You can use two methods to configure the system to enforce these features:
Method: Access Control Rules
Content restriction features communicate the restricted status of a search or content query via an element
in the request URI, an associated cookie, or a custom HTTP header element. You can configure access
control rules to modify these elements as the system processes traffic.
Method: DNS Sinkhole
For Google searches, you can configure the system to redirect traffic to the Google SafeSearch Virtual
IP Address (VIP), which imposes filters for Safe Search (including YouTube Restricted Mode).

Firepower Management Center Configuration Guide, Version 6.3

1443
 Access Control
Using Access Control Rules to Enforce Content Restriction

The table below describes the differences between these enforcement methods.

Table 95: Comparison of Content Restriction Methods

Attribute Method: Access Control Rules Method: DNS Sinkhole

Supported devices Any Firepower Threat Defense only

Search engines supported Any tagged safesearch Google only
supported in the Applications
tab of the rule editor

YouTube Restricted Mode Yes Yes

supported
YouTube EDU supported Yes No

SSL policy required Yes No

Hosts must be using IPv4 No Yes

Connection event logging Yes Yes

When determining which method to use, consider the following limitations:

• The access control rules method requires an SSL policy, which impacts performance.
• The Google SafeSearch VIP supports IPv4 traffic only. If you configure a DNS sinkhole to manage
Google searches, any hosts on the affected network must be using IPv4.

The system logs different values for the Reason field in connection events, depending on the method:
• Access Control Rules—Content Restriction
• DNS Sinkhole—DNS Block

Using Access Control Rules to Enforce Content Restriction

Smart License Classic License Supported Devices Supported Domains Access

Any Control Any Any Admin/Access

Admin/Network
Admin

Caution To avoid rule preemption, position rules governing YouTube EDU above rules governing Safe Search in both
SSL and access control policies; see Content Restriction Rule Order, on page 355.

Firepower Management Center Configuration Guide, Version 6.3

1444
Access Control
Using Access Control Rules to Enforce Content Restriction

Procedure

Step 1 Create an SSL policy; see Create Basic SSL Policies, on page 1479.
Step 2 Add SSL rules for handling Safe Search and YouTube EDU traffic:
• Choose Decrypt - Resign as the Action for the rules. The system does not support any other action for
content restriction handling.
• In the Applications tab, add selections to the Selected Applications and Filters list:
• YouTube EDU—Add the YouTube and YouTube Upload applications.
• Safe Search—Add the Category: search engine filter.

For more information, see Adding an Application Condition to a TLS/SSL Rule, on page 1511.

Step 3 Set rule positions for the SSL rules you added. Click and drag, or use the right-click menu to cut and paste.
To avoid preemption, position the Safe Search rule after the YouTube EDU rule.

Step 4 Create or edit an access control policy, and associate the SSL policy with the access control policy.
For more information, see Associating Other Policies with Access Control, on page 1365.

Step 5 In the access control policy, add rules for handling Safe Search and YouTube EDU traffic:
• Choose Allow as the Action for the rules. The system does not allow any other action for content restriction
handling.

• In the Applications tab, click the dimmed icon for either Safe Search ( ) or YouTube EDU ( ), and
set related options; see Safe Search Options for Access Control Rules, on page 1446 and YouTube EDU
Options for Access Control Rules, on page 1446.
These icons are disabled, rather than dimmed, if you choose any Action other than Allow for the rule.
You cannot enable Safe Search and YouTube EDU restrictions for the same access control rule.
• In the Applications tab, refine application selections in the Selected Applications and Filters list.
In most cases, enabling Safe Search or YouTube EDU populates the Selected Applications and Filters
list with the appropriate values. The system does not automatically populate the list if a Safe Search or
YouTube application is already present in the list when you enable the feature. If applications do not
populate as expected, manually add them as follows:
• YouTube EDU—Add the YouTube and YouTube Upload applications.
• Safe Search—Add the Category: search engine filter.

For more information, see Configuring Application Conditions and Filters, on page 336.

Step 6 Set rule positions for the access control rules you added. Click and drag, or use the right-click menu to cut
and paste.
To avoid preemption, position the Safe Search rule after the YouTube EDU rule.

Step 7 Configure the HTTP response page that the system displays when it blocks restricted content; see Choosing
HTTP Response Pages, on page 1402.

Firepower Management Center Configuration Guide, Version 6.3

1445
 Access Control
Safe Search Options for Access Control Rules

Step 8 Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Safe Search Options for Access Control Rules

The Firepower System supports Safe Search filtering for specific search engines only. For a list of supported
search engines, see applications tagged safesearch supported in the Applications tab of the access
control rule editor. For a list of unsupported search engines, see applications tagged safesearch
unsupported.
When enabling Safe Search for an access control rule, set the following parameters:
Enable Safe Search
Enables Safe Search filtering for traffic that matches this rule.
Unsupported Search Traffic
Specifies the action you want the system to take when it processes traffic from unsupported search
engines. If you choose Block or Block with Reset, you must also configure the HTTP response page
that the system displays when it blocks restricted content; see Choosing HTTP Response Pages, on page
1402.

YouTube EDU Options for Access Control Rules

When enabling YouTube EDU for an access control rule, set the following parameters:
Enable YouTube EDU
Enables YouTube EDU filtering for traffic that matches this rule.
Custom ID
Specifies the value that uniquely identifies a school or district network in the YouTube EDU initiative.
YouTube provides this ID when a school or district registers for a YouTube EDU account.

Note If you check Enable YouTube EDU, you must enter a Custom ID. This ID is defined externally by
YouTube. The system does not validate what you enter against the YouTube system. If you enter an
invalid ID, YouTube EDU restrictions may not perform as expected.

Using a DNS Sinkhole to Enforce Content Restriction

Smart License Classic License Supported Devices Supported Domains Access

Threat Protection Firepower Threat Any Admin/Access

Defense Admin/Network
Admin

Typically, a DNS sinkhole directs traffic away from a particular target. This procedure describes how to
configure a DNS sinkhole to redirect traffic to the Google SafeSearch Virtual IP Address (VIP), which imposes
content filters on Google and YouTube search results.
Because Google SafeSearch uses a single IPv4 address for the VIP, hosts must use IPv4 addressing.

Firepower Management Center Configuration Guide, Version 6.3

1446
Access Control
Using a DNS Sinkhole to Enforce Content Restriction

Caution If your network includes proxy servers, this content restriction method is not effective unless you position
your Firepower Threat Defense devices between the proxy servers and the Internet.

This procedure describes enforcing content restriction for Google searches only. To enforce content restriction
for other search engines, see Using Access Control Rules to Enforce Content Restriction, on page 1444.

Procedure

Step 1 Obtain a list of supported Google domains via the following URL: https://www.google.com/supported_
domains.
Step 2 Create a custom DNS list on your local computer, and add the following entries:
• To enforce Google SafeSearch, add an entry for each supported Google domain.
• To enforce YouTube Restricted Mode, add a "youtube.com" entry.
The custom DNS list must be in text file (.txt) format. Each line of the text file must specify an individual
domain name, stripped of any leading periods. For example, the supported domain ".google.com" must appear
as "google.com".

Step 3 Upload the custom DNS list to the Firepower Management Center; see Uploading New Security Intelligence
Lists to the Firepower Management Center, on page 404.
Step 4 Determine the IPv4 address for the Google SafeSearch VIP. For example, run nslookup on
forcesafesearch.google.com.
Step 5 Create a sinkhole object for the SafeSearch VIP; see Creating Sinkhole Objects, on page 406.
Use the following values for this object:
• IPv4 Address—Enter the SafeSearch VIP address.
• IPv6 Address—Enter the IPv6 loopback address (::1).
• Log Connections to Sinkhole—Click this radio button.
• Type—Choose None.

Step 6 Create a basic DNS policy; see Creating Basic DNS Policies, on page 1413.
Step 7 Add a DNS rule for the sinkhole; see Creating and Editing DNS Rules, on page 1415.
For this rule:
• Check the Enabled check box.
• Choose Sinkhole from the Action drop-down list.
• Choose the sinkhole object you created from the Sinkhole drop-down list.
• Add the custom DNS list you created to the Selected Items list on the DNS tab.
• (Optional) Choose a network in the Networks tab to limit content restriction to specific users. For
example, if you want to limit content restriction to student users, assign students to a different subnet
than faculty, and specify that subnet in this rule.

Firepower Management Center Configuration Guide, Version 6.3

1447
 Access Control
Using a DNS Sinkhole to Enforce Content Restriction

Step 8 Associate the DNS policy with an access control policy; see Associating Other Policies with Access Control,
on page 1365.
Step 9 Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1448
PA R T XVIII
Encrypted Traffic Handling
• Understanding Traffic Decryption, on page 1451
• Start Creating SSL Policies, on page 1475
• Get Started with TLS/SSL Rules, on page 1483
• Decryption Tuning Using TLS/SSL Rules, on page 1499
• Monitor SSL Hardware Acceleration, on page 1531
• Troubleshoot TLS/SSL Rules, on page 1535
 CHAPTER 72
Understanding Traffic Decryption
The following topics provide an overview of Transport Layer Security/Secure Sockets Layer (TLS/SSL)
inspection, discuss the prerequisites for TLS/SSL inspection configuration, and detail deployment scenarios.

Note Because TLS and SSL are often used interchangeably, we use the expression TLS/SSL to indicate that either
protocol is being discussed. The SSL protocol has been deprecated by the IETF in favor of the more secure
TLS protocol, so you can usually interpret TLS/SSL as referring to TLS only.
The exception is SSL policies. Because the FMC configuration option is Policies > Access Control > SSL,
we use the term SSL policies although these policies are used to define rules for TLS and SSL traffic.
For more information about SSL and TLS protocols, see a resource such as SSL vs. TLS - What's the
Difference?.

• About Traffic Decryption, on page 1451

• TLS/SSL Handshake Processing, on page 1452
• TLS/SSL Hardware Acceleration, on page 1456
• TLS/SSL Inspection Requirements, on page 1459
• TLS/SSL Inspection Appliance Deployment Scenarios, on page 1460
• History for TLS/SSL, on page 1473

About Traffic Decryption

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. As the
system handles encrypted sessions, it logs details about the traffic. The combination of inspecting encrypted
traffic and analyzing encrypted session data allows greater awareness and control of the encrypted applications
and traffic in your network.
TLS/SSL inspection is a policy-based feature. In the Firepower System, an access control policy is a master
configuration that invokes subpolicies and other configurations, including an SSL policy. If you associate an
SSL policy with access control, the system uses that SSL policy to handle encrypted sessions before it evaluates
them with access control rules. If you do not configure TLS/SSL inspection, or your devices do not support
it, access control rules handle all encrypted traffic.

Firepower Management Center Configuration Guide, Version 6.3

1451
 Encrypted Traffic Handling
TLS/SSL Handshake Processing

Note that access control rules also handle encrypted traffic when your TLS/SSL inspection configuration
allows it to pass. However, some access control rule conditions require unencrypted traffic, so encrypted
traffic might match fewer rules. Also, by default, the system disables intrusion and file inspection of encrypted
payloads. This helps reduce false positives and improves performance when an encrypted connection matches
an access control rule that has intrusion and file inspection configured.
If the system detects a TLS/SSL handshake over a TCP connection, it determines whether it can decrypt the
detected traffic. If it cannot, it applies a configured action:
• Block the encrypted traffic
• Block the encrypted traffic and reset the TCP connection
• Not decrypt the encrypted traffic

If the system can decrypt the traffic, it blocks the traffic without further inspection, evaluates undecrypted
traffic with access control, or decrypts it using one of the following methods:
• Decrypt with a known private key. When an external host initiates a TLS/SSL handshake with a server
on your network, the system matches the exchanged server certificate with a server certificate previously
uploaded to the system. It then uses the uploaded private key to decrypt the traffic.
• Decrypt by resigning the server certificate. When a host on your network initiates a TLS/SSL handshake
with an external server, the system resigns the exchanged server certificate with a previously uploaded
certificate authority (CA) certificate. It then uses the uploaded private key to decrypt the traffic.

Decrypted traffic is subject to the same traffic handling and analysis as originally unencrypted traffic: network,
reputation, and user-based access control; intrusion detection and prevention; Cisco Advanced Malware
Protection (Cisco AMP); and discovery. If the system does not block the decrypted traffic post-analysis, it
re-encrypts the traffic before passing it to the destination host.

Note Set up decrypt rules only if your managed device handles encrypted traffic. Decryption rules require processing
overhead that can impact performance.

TLS/SSL Handshake Processing

In this documentation, the term TLS/SSL handshake represents the two-way handshake that initiates encrypted
sessions in both the SSL protocol and its successor protocol, TLS.
In a passive deployment, the Firepower System observes a copy of the handshake, but does not process the
actual handshake. In an inline deployment, the Firepower System processes the TLS/SSL handshake, potentially
modifying the ClientHello message and acting as a TCP proxy server for the session.
After the client establishes a TCP connection with the server (after it successfully completes the TCP three-way
handshake), the managed device monitors the TCP session for any attempt to initiate an encrypted session.
The TLS/SSL handshake establishes an encrypted session via the exchange of specialized packets between
client and server. In the SSL and TLS protocols, these specialized packets are called handshake messages.
The handshake messages communicate which encryption attributes both the client and server support:
• ClientHello—The client specifies multiple supported values for each encryption attribute.

Firepower Management Center Configuration Guide, Version 6.3

1452
 Encrypted Traffic Handling
ClientHello Message Handling

• ServerHello—The server specifies a single supported value for each encryption attribute, which determines
which encryption method the system uses during the secure session.

Although the data transmitted in the session is encrypted, the handshake messages are not.
After a TLS/SSL handshake completes, the managed device caches encrypted session data, which allows
session resumption without requiring the full handshake. The managed device also caches server certificate
data, which allows faster handshake processing in subsequent sessions.

ClientHello Message Handling

The client sends the ClientHello message to the server that acts as the packet destination if a secure connection
can be established. The client sends the message to initiate the TLS/SSL handshake or in response to a Hello
Request message from the destination server.
If you configure TLS/SSL decryption, when a managed device receives a ClientHello message, the system
attempts to match the message to TLS/SSL rules that have the Decrypt - Resign action. The match relies on
data from the ClientHello message and from cached server certificate data. Possible data includes:

Table 96: Data Availability for TLS/SSL Rule Conditions

TLS/SSL Rule Condition Data Present In

Zones ClientHello

Networks ClientHello

VLAN Tags ClientHello

Ports ClientHello

Users ClientHello

Applications ClientHello (Server Name Indicator extension)

Categories ClientHello (Server Name Indicator extension)

Certificate server Certificate (potentially cached)

Distinguished Names server Certificate (potentially cached)

Certificate Status server Certificate (potentially cached)

Cipher Suites ServerHello

Versions ServerHello

If the ClientHello message does not match a Decrypt - Resign rule, the system does not modify the message.
It then determines whether the message passes access control evaluation (which can include deep inspection).
If the message passes, the system transmits it to the destination server.
If the message matches a Decrypt - Resign rule, the system modifies the ClientHello message as follows:

Firepower Management Center Configuration Guide, Version 6.3

1453
 Encrypted Traffic Handling
ClientHello Message Handling

• Compression methods—Strips the compression_methods element, which specifies the compression

methods the client supports. The Firepower System cannot decrypt compressed sessions. This modification
reduces the Compressed Session type of undecryptable traffic.
• Cipher suites—Strips cipher suites from the cipher_suites element if the Firepower System does not
support them. If the Firepower System does not support any of the specified cipher suites, the system
transmits the original, unmodified element. This modification reduces the Unknown Cipher Suite and
Unsupported Cipher Suite types of undecryptable traffic.
• Session identifiers—Strips any value from the Session Identifier element and the SessionTicket
extension that does not match cached session data. If a ClientHello value matches cached data, an
interrupted session can resume without the client and server performing the full TLS/SSL handshake.
This modification increases the chances of session resumption and reduces the Session Not Cached type
of undecryptable traffic.
• Elliptic curves—Strips elliptic curves from the Supported Elliptic Curves extension if the Firepower
System does not support them. If the Firepower System does not support any of the specified elliptic
curves, the managed device removes the extension and strips any related cipher suites from the
cipher_suites element.

• ALPN extensions—Strips any value from the Application-Layer Protocol Negotiation (ALPN) extension
that is unsupported in the Firepower System (for example, the SPDY and HTTP/2 protocols).
• Other Extensions—Strips the Extended Master Secret, Next Protocol Negotiation (NPN), and TLS
Channel IDs extensions.

Note The system performs these ClientHello modifications by default. If your SSL policy is configured correctly,
this default behavior results in more frequent decryption of traffic. To tune the default behavior for your
individual network, contact Cisco TAC.

After the system modifies the ClientHello message, it determines whether the message passes access control
evaluation (which can include deep inspection). If the message passes, the system transmits it to the destination
server.
Direct communication between the client and server is no longer possible during the TLS/SSL handshake,
because after message modification the Message Authentication Codes (MACs) computed by the client and
server no longer match. For all subsequent handshake messages (and for the encrypted session once established),
the managed device acts as a man-in-the-middle (MITM). It creates two TLS/SSL sessions, one between client
and managed device, one between managed device and server. As a result, each session contains different
cryptographic session details.

Note The cipher suites that the Firepower System can decrypt are frequently updated and do not correspond directly
to the cipher suites you can use in TLS/SSL rule conditions. For the current list of decryptable cipher suites,
contact Cisco TAC.

Related Topics
Default Handling Options for Undecryptable Traffic, on page 1477
Encrypted Traffic Inspection with a Re-signed Certificate in an Inline Deployment, on page 1471

Firepower Management Center Configuration Guide, Version 6.3

1454
 Encrypted Traffic Handling
ServerHello and Server Certificate Message Handling

ServerHello and Server Certificate Message Handling

The ServerHello message is the response to a ClientHello message in a successful TLS/SSL handshake.
After a managed device processes a ClientHello message and transmits it to the destination server, the server
determines whether it supports the decryption attributes the client specified in the message. If it does not
support those attributes, the server sends a handshake failure alert to the client. If it supports those attributes,
the server sends the ServerHello message. If the agreed-upon key exchange method uses certificates for
authentication, the server Certificate message immediately follows the ServerHello message.
When the managed device receives these messsages, it attempts to match them with TLS/SSL rules. These
messages contain information that was absent from either the ClientHello message or the session data cache.
Specifically, the system can potentially match these messages on Distinguished Names, Certificate Status,
Cipher Suites, and Versions conditions.
If the messages do not match any TLS/SSL rules, the managed device performs the default action for the SSL
policy. For more information, see SSL Policy Default Actions, on page 1476.
If the messages match an SSL rule, the managed device continues as appropriate:
Action: Monitor
The TLS/SSL handshake continues to completion. The managed device tracks and logs but does not
decrypt encrypted traffic.
Action: Block or Block with Reset
The managed device blocks the TLS/SSL session. If appropriate, it also resets the TCP connection.
Action: Do Not Decrypt
The TLS/SSL handshake continues to completion. The managed device does not decrypt the application
data exchanged during the TLS/SSL session.
Action: Decrypt - Known Key
The managed device attempts to match the server certificate data to an Internal Certificate object previously
imported into the Firepower Management Center. Because you cannot generate an Internal Certificate
object, and you must possess its private key, we assume you own the server on which you're using known
key decryption.
If the certificate matches a known certificate, the TLS/SSL handshake continues to completion. The
managed device uses the uploaded private key to decrypt and reencrypt the application data exchanged
during the TLS/SSL session.
If the server changes its certificate between the initial connection with the client and subsequent
connections, you must import the new server certificate in the Firepower Management Center for future
connections to be decrypted.

Note Because the Firepower System does not support the Extended Master Secret extension defined by RFC
7627, you must disable this extension on the server for which you're decrypting with a known key;
otherwise, the connection is reset during decryption, resulting in connection errors.

Action: Decrypt - Resign

The managed device processes the server certificate message and re-signs the server certificate with the
previously imported or generated certificate authority (CA). The TLS/SSL handshake continues to

Firepower Management Center Configuration Guide, Version 6.3

1455
 Encrypted Traffic Handling
TLS/SSL Hardware Acceleration

completion. The managed device then uses the uploaded private key to decrypt and reencrypt the
application data exchanged during the TLS/SSL session.

TLS/SSL Hardware Acceleration

Certain Firepower managed device models support Transport Layer Security/Secure Sockets Layer (TLS/SSL)
encryption and decryption acceleration in hardware, greatly improving performance.
TLS/SSL hardware acceleration is automatically enabled on all devices that support it except for devices for
which FTD container instance is enabled. Only native instances support TLS/SSL hardware acceleration.

Supported Hardware
The following hardware models support TLS/SSL hardware acceleration:
• Firepower 9300 security module with Firepower Threat Defense
• Firepower 4100 security engine with Firepower Threat Defense
• Firepower 2100 with Firepower Threat Defense

TLS/SSL hardware acceleration is not supported on any virtual appliances or on any hardware except for the
preceding.

Features Supported by TLS/SSL hardware acceleration

Features supported by TLS/SSL hardware acceleration include the following:
• IPv4-in-IPv4 tunneled protocols only are supported; other tunneled IP protocols are not supported.
• Decryption of TLS/SSL traffic encapsulated in Generic Routing Encapsulation (GRE) tunnels

Features Not Supported by TLS/SSL hardware acceleration

Features not supported by TLS/SSL hardware acceleration include the following:
• Decryption of TLS/SSL traffic using passive network or inline tap mode interfaces.
• Managed devices where FTD container instance is enabled.
• If the inspection engine is configured to preserve connections and the inspection engine fails unexpectedly,
TLS/SSL traffic is dropped until the engine restarts.
This behavior is controlled by the configure snort preserve-connection {enable | disable} command.

If you need to use any of the preceding features, you can disable TLS/SSL hardware acceleration.

Enable or Disable TLS/SSL Hardware Acceleration

Use the following commands to enable or disable TLS/SSL hardware acceleration on a managed device:

system support {ssl-hw-offload enable | ssl-hw-offload disable}

Firepower Management Center Configuration Guide, Version 6.3

1456
 Encrypted Traffic Handling
TLS/SSL Hardware Acceleration Guidelines and Limitations

Syntax Description ssl-hw-offload enable Enables TLS/SSL hardware acceleration; you are prompted to reboot the device.
(Enabled by default.)

ssl-hw-offload disable Disables TLS/SSL hardware acceleration; you are prompted to reboot the device.

TLS/SSL Hardware Acceleration Guidelines and Limitations

Keep the following in mind if your managed device has TLS/SSL hardware acceleration enabled.

HTTP-only performance
Using TLS/SSL hardware acceleration on a managed device that is not decrypting traffic can affect performance.
We recommend you disable TLS/SSL hardware acceleration on devices that are not decrypting traffic.

Federal Information Processing Standards (FIPS)

If TLS/SSL hardware acceleration and Federal Information Processing Standards (FIPS) are both enabled,
connections with the following options fail:
• RSA keys less than 2048 bytes in size
• Rivest cipher 4 (RC4)
• Single Data Encryption Standard (single DES)
• Merkle–Damgard 5 (MD5)
• SSL v3

FIPS is enabled when you configure the Firepower Management Center and managed devices to operate in
a security certifications compliance mode. To allow connections when operating in those modes, you can
either disable TLS/SSL hardware acceleration or configure web browsers to accept more secure options.
For more information:
• Enable or disable TLS/SSL hardware acceleration: TLS/SSL Hardware Acceleration, on page 1456.
• Ciphers supported by FIPS: About SSL Settings, on page 1103.
• Security Certifications Compliance Modes, on page 1135.
• Common Criteria.

TLS/SSL hardware acceleration and newer devices

Certain unsecure cipher suites are not supported in newer hardware models when TLS/SSL hardware
acceleration is enabled, including managed devices and service modules that can be optionally installed in
those devices.
To show the list of supported ciphers, use the system support ssl-hw-supported-ciphers command as
discussed in the Command Reference for Firepower Threat Defense.
We recommend you set the SSL policy's Undecryptable Actions for Unsupported Cipher Suite appropriately
for unsupported ciphers:
• Do not decrypt

Firepower Management Center Configuration Guide, Version 6.3

1457
 Encrypted Traffic Handling
TLS/SSL Hardware Acceleration Guidelines and Limitations

• Block
• Block with reset

For more information, see Default Handling Options for Undecryptable Traffic, on page 1477.
For more information about unsecure cipher suites, see a reference like the following:
• Open Web Application Security Project (OWASP) TLS Cheat Sheet section on server protocol and cipher
configuration
• OWASP testing guidelines
• SSL Labs' SSL and TLS Deployment Best Practices

High Availability (HA)

If you have high availability (HA) or clustered managed devices, you must enable TLS/SSL hardware
acceleration on each managed device individually. One device's TLS/SSL hardware acceleration configuration
is not shared with the other device in the HA pair.

TLS heartbeat
Some applications use the TLS heartbeat extension to the Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS) protocols defined by RFC6520. TLS heartbeat provides a way to confirm
the connection is still alive—either the client or server sends a specified number of bytes of data and requests
the other party echo the response. If this is successful, encrypted data is sent.
When a managed device with TLS/SSL hardware acceleration enabled encounters a packet that uses the TLS
heartbeat extension,the managed device takes the action specified by the setting for Decryption Errors in
the SSL policy's Undecryptable Actions:
• Block
• Block with reset

For more information, see Default Handling Options for Undecryptable Traffic, on page 1477.
To determine whether applications are using TLS heartbeat, see Troubleshoot TLS Heartbeat, on page 1538.
If your managed device does not support TLS/SSL hardware acceleration or if is disabled, you can configure
a Max Heartbeat Length in a Network Analysis Policy (NAP) to determine how to handle TLS heartbeats.
For more information, see The SSL Preprocessor, on page 1931.

TLS/SSL oversubscription
TLS/SSL oversubscription is a state where a managed device is overloaded with TLS/SSL traffic. Any managed
device can experience TLS/SSL oversubscription but only managed devices that support TLS/SSL hardware
acceleration provide a configurable way to handle it.
When a managed device with TLS/SSL hardware acceleration enabled is oversubscribed, any packet received
by the managed device is acted on according to the setting for Handshake Errors in the SSL policy's
Undecryptable Actions:
• Inherit default action
• Do not decrypt

Firepower Management Center Configuration Guide, Version 6.3

1458
 Encrypted Traffic Handling
View the Status of TLS/SSL Hardware Acceleration

• Block
• Block with reset

If the setting for Handshake Errors in the SSL policy's Undecryptable Actions is Do Not decrypt and the
associated access control policy is configured to inspect the traffic, inspection occurs; decryption does not
occur.
If a significant amount of oversubscription is occurring, you have the following options:
• Upgrade your managed devices to increase TLS/SSL processing capacity.
• Change your SSL policies to add Do Not Decrypt rules for traffic that is not a high priority to decrypt.

Passive and inline tap mode interfaces not supported

TLS/SSL traffic cannot be decrypted on passive or inline tap mode interfaces when TLS/SSL hardware
acceleration is enabled.

View the Status of TLS/SSL Hardware Acceleration

This topic discusses how you can determine if TLS/SSL hardware acceleration is enabled on your managed
device. Only certain managed devices support this feature; for more information, see TLS/SSL Hardware
Acceleration, on page 1456.

Procedure

Step 1 Log in to the Firepower Management Center.

Step 2 Click Devices > Device Management.

Step 3 Click (edit) to edit a managed device.

Step 4 Click the Device tab page. TLS/SSL hardware acceleration status is displayed in the General section.

Related Topics
TLS/SSL Hardware Acceleration, on page 1456
TLS/SSL Hardware Acceleration Guidelines and Limitations, on page 1457
View the Status of TLS/SSL Hardware Acceleration, on page 1459

TLS/SSL Inspection Requirements

How you deploy the appliances on your network, in addition to your configuration settings and licenses,
influences the actions you can take to control and decrypt encrypted traffic. Review your list of mapped
actions, existing network deployment, and overall requirements to determine whether one or the other type
of deployment better suits your organization.
Devices configured and deployed with inline, routed, switched, or hybrid interfaces can modify the flow of
traffic. These devices can monitor, block, allow, and decrypt incoming and outgoing traffic.

Firepower Management Center Configuration Guide, Version 6.3

1459
 Encrypted Traffic Handling
TLS/SSL Rules Configuration Prerequisite Information

Devices configured and deployed with passive or inline (tap mode) interfaces cannot affect the flow of traffic.
They can only monitor, allow, and decrypt incoming traffic. Note that passive deployments do not support
decrypting traffic encrypted with the ephemeral Diffie-Hellman (DHE) or the elliptic curve Diffie-Hellman
(ECDHE) cipher suites.
TLS/SSL inspection requires public key certificates and paired private keys for certain features. You must
upload certificates and paired private keys to the Firepower Management Center to decrypt and control traffic
based on encryption session characteristics.

TLS/SSL Rules Configuration Prerequisite Information

TLS/SSL inspection relies on a significant amount of supporting public key infrastructure (PKI) information.
Consider your organization’s traffic patterns to determine the matching rule conditions you can configure.

Table 97: TLS/SSL Rule Condition Prerequisites

To match on... Collect the...

detected server certificates, including self-signed server certificates server certificate

trusted server certificates CA certificate

detected server certificate subject or issuer server certificate subject DN or issuer DN

After you have collected this information, upload it to the system and configure reusable objects.
Related Topics
Distinguished Name Objects, on page 413
PKI Objects, on page 415

TLS/SSL Inspection Appliance Deployment Scenarios

This section presents several scenarios in which the Life Insurance Example, Inc. life insurance company
(LifeIns) uses SSL inspection on encrypted traffic to help audit their processes. Based on their business
processes, LifeIns plans to deploy:
• one 7000 or 8000 Series device in a passive deployment for the Customer Service department
• one 7000 or 8000 Series device in an inline deployment for the Underwriting Department
• one Firepower Management Center to manage both devices

Customer Service Business Processes

LifeIns created a customer-facing website for their customers. LifeIns receives encrypted questions and
requests regarding policies from prospective customers through their website and through e-mail. LifeIns’s
Customer Service department processes them and returns the requested information within 24 hours. Customer
Service wants to expand its incoming contact metrics collection. LifeIns has an established internal audit
review for Customer Service.

Firepower Management Center Configuration Guide, Version 6.3

1460
 Encrypted Traffic Handling
Traffic Decryption in a Passive Deployment

LifeIns also receives encrypted applications online. The Customer Service department processes the applications
within 24 hours before sending the case file to the Underwriting department. Customer Service filters out any
obvious false applications sent through the online form, which consumes a fair portion of their time.

Underwriting Business Processes

LifeIns’s underwriters submit encrypted medical information requests online to the Medical Repository
Example, LLC medical data repository (MedRepo). MedRepo reviews the requests and transmits the encrypted
records to LifeIns within 72 hours. The underwriters subsequently underwrite an application and submit policy
and rate decisions. Underwriting wants to expand its metrics collection.
Lately, an unknown source has been sending spoofed responses to LifeIns. Though LifeIns’s underwriters
receive training on proper Internet use, LifeIns’s IT department first wants to analyze all encrypted traffic
that takes the form of medical responses, then wants to block all spoof attempts.
LifeIns places junior underwriters on six-month training periods. Lately, these underwriters have been
incorrectly submitting encrypted medical regulation requests to MedRepo’s customer service department.
MedRepo has submitted multiple complaints to LifeIns in response. LifeIns plans on extending their new
underwriter training period to also audit underwriter requests to MedRepo.

Traffic Decryption in a Passive Deployment

LifeIns’s business requirements state that Customer Service must:
• process all requests and applications within 24 hours
• improve its incoming contact metrics collection process
• identify and discard incoming false applications

Customer Service does not require additional audit review.

LifeIns plans to passively deploy a Customer Service managed device.

Traffic from an external network goes to LifeIns’s router. The router routes traffic to the Customer Service
department, and mirrors a copy of the traffic to the managed device for inspection.
On the managing Firepower Management Center, a user in the access control configures TLS/SSL inspection
to:
• log all encrypted traffic sent to the Customer Service department

Firepower Management Center Configuration Guide, Version 6.3

1461
 Encrypted Traffic Handling
Encrypted Traffic Monitoring in a Passive Deployment

• decrypt encrypted traffic sent using the online application form to Customer Service
• not decrypt all other encrypted traffic sent to Customer service, including traffic sent using the online
request form

The user also configures access control to inspect the decrypted application form traffic for fake application
data and log when fake data is detected.
In the following scenarios, the user submits an online form to Customer Service. The user’s browser establishes
a TCP connection with the server, then initiates a TLS/SSL handshake. The managed device receives a copy
of this traffic. The client and server complete the TLS/SSL handshake, establishing the encrypted session.
Based on handshake and connection details, the system logs the connection and acts upon the copy of the
encrypted traffic.

Encrypted Traffic Monitoring in a Passive Deployment

For all TLS/SSL-encrypted traffic sent to Customer Service, the managed device logs the connection.

The following steps occur:

1. The user submits the plain text request (info). The client encrypts this (AaBb) and sends the encrypted
traffic to Customer Service.
2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It
also mirrors a copy to the managed device.
3. The Customer Service department server receives the encrypted information request (AaBb) and decrypts
it to plain text (info).
4. The managed device does not decrypt the traffic.
The access control policy continues to process the encrypted traffic and allows it. The device generates
a connection event after the session ends.
5. The Firepower Management Center receives the connection event.

Firepower Management Center Configuration Guide, Version 6.3

1462
 Encrypted Traffic Handling
Undecrypted Encrypted Traffic in a Passive Deployment

Undecrypted Encrypted Traffic in a Passive Deployment

For all TLS/SSL-encrypted traffic that contains requests about policies, the managed device allows the traffic
without decrypting it and logs the connection.

The following steps occur:

1. The user submits the plain text request (info). The client encrypts this (AaBb) and sends the encrypted
traffic to Customer Service.
2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It
also mirrors a copy to the managed device.
3. The Customer Service department server receives the encrypted information request (AaBb) and decrypts
it to plain text (info).
4. The managed device does not decrypt the traffic.
The access control policy continues to process the encrypted traffic and allows it. The device generates
a connection event after the session ends.
5. The Firepower Management Center receives the connection event.

Encrypted Traffic Inspection with a Private Key in a Passive Deployment

For all TLS/SSL-encrypted traffic that contains application form data, the system decrypts the traffic and logs
the connection.

Note In a passive deployment, if traffic is encrypted with either the DHE or ECDHE cipher suite, you cannot decrypt
it with a known private key.

For traffic with legitimate application form information, the system logs the connection.

Firepower Management Center Configuration Guide, Version 6.3

1463
 Encrypted Traffic Handling
Encrypted Traffic Inspection with a Private Key in a Passive Deployment

The following steps occur:

1. The user submits the plain text request (form). The client encrypts this (AaBb) and sends the encrypted
traffic to Customer Service.
2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It
also mirrors a copy to the managed device.
3. The Customer Service department server receives the encrypted information request (AaBb) and decrypts
it to plain text (form).
4. The managed device uses the session key obtained with the uploaded known private key to decrypt the
encrypted traffic to plain text (form).
The access control policy continues to process the decrypted traffic and does not find fake application
information. The device generates a connection event after the session ends.
5. The Firepower Management Center receives a connection event with information about the encrypted
and decrypted traffic.

In contrast, if the decrypted traffic contains fake application data, the system logs the connection and the fake
data.

Firepower Management Center Configuration Guide, Version 6.3

1464
 Encrypted Traffic Handling
Traffic Decryption in an Inline Deployment

The following steps occur:

1. The user submits the plain text request (fake). The client encrypts this (CcDd) and sends the encrypted
traffic to Customer Service.
2. LifeIns's router receives the encrypted traffic and routes it to the Customer Service department server. It
also mirrors a copy to the managed device.
3. The Customer Service department server receives the encrypted information request (CcDd) and decrypts
it to plain text (fake).
4. The managed device uses the session key obtained with the uploaded known private key to decrypt the
encrypted traffic to plain text (fake).
The access control policy continues to process the decrypted traffic and finds fake application information.
The device generates an intrusion event. After the session ends, it generates a connection event.
5. The Firepower Management Center receives a connection event with information about the encrypted
and decrypted traffic, and an intrusion event for the fake application data.

Traffic Decryption in an Inline Deployment

LifeIns’s business requirements state that Underwriting must:
• audit new and junior underwriters, verifying that their information requests to MedRepo comply with
all applicable regulations
• improve its underwriting metrics collection process
• examine all requests that appear to come from MedRepo, then drop any spoofing attempts
• drop all improper regulatory requests to MedRepo’s Customer Service department from the Underwriting
department
• not audit senior underwriters

LifeIns plans to deploy a device in an inline deployment for the Underwriting department.

Firepower Management Center Configuration Guide, Version 6.3

1465
 Encrypted Traffic Handling
Traffic Decryption in an Inline Deployment

Traffic from MedRepo’s network goes to MedRepo’s router. It routes traffic to LifeIns’s network. The managed
device receives the traffic, passes allowed traffic to LifeIns’s router, and sends events to the managing Firepower
Management Center. LifeIns’s router routes traffic to the destination host.
On the managing Firepower Management Center, a user in the Access Control and SSL Editor custom role
configures an SSL access control rule to:
• log all encrypted traffic sent to the Underwriting department
• block all encrypted traffic incorrectly sent from LifeIns’s underwriting department to MedRepo’s customer
service department
• decrypt all encrypted traffic sent from MedRepo to LifeIns’s underwriting department, and from LifeIns’s
junior underwriters to MedRepo’s requests department
• not decrypt encrypted traffic sent from the senior underwriters

The user also configures access control to inspect decrypted traffic with a custom intrusion policy and:
• block decrypted traffic if it contains a spoof attempt, and log the spoof attempt
• block decrypted traffic that contains information not compliant with regulations, and log the improper
information
• allow all other encrypted and decrypted traffic

The system reencrypts allowed decrypted traffic before sending it to the destination host.
You can also cause the system to decrypt and resign the traffic using a TLS/SSL control rule with the action
Decrypt - Resign. If traffic matches the TLS/SSL rule, after the system modifies the ClientHello message, it
determines whether the message passes access control evaluation (which can include deep inspection). If the
message passes, the system transmits it to the destination server. For more information, see ClientHello
Message Handling, on page 1453
In the following scenarios, the user submits information online to a remote server. The user’s browser establishes
a TCP connection with the server, then initiates an SSL handshake. The managed device receives this traffic;
based on handshake and connection details, the system logs the connection and acts on the traffic. If the system
blocks the traffic, it also closes the TCP connection. Otherwise, the client and server complete the SSL
handshake, establishing the encrypted session.

Firepower Management Center Configuration Guide, Version 6.3

1466
 Encrypted Traffic Handling
Encrypted Traffic Monitoring in an Inline Deployment

Encrypted Traffic Monitoring in an Inline Deployment

For all SSL-encrypted traffic sent to and from the Underwriting department, the system logs the connection.

The following steps occur:

1. The user submits the plain text request (help). The client encrypts this (AaBb) and sends the encrypted
traffic to MedRepo’s Requests department server.
2. LifeIns's router receives the encrypted traffic and routes it to the Requests department server.
3. The managed device does not decrypt the traffic.
The access control policy continues to process the encrypted traffic and allows it, then generates a
connection event after the session ends.
4. The external router receives the traffic and routes it to the Requests department server.
5. The Underwriting department server receives the encrypted information request (AaBb) and decrypts it to
plain text (help).
6. The Firepower Management Center receives the connection event.

Undecrypted Encrypted Traffic in an Inline Deployment

For all TLS/SSL-encrypted traffic originating from the senior underwriters, the managed device allows the
traffic without decrypting it and logs the connection.

Firepower Management Center Configuration Guide, Version 6.3

1467
 Encrypted Traffic Handling
Encrypted Traffic Blocking in an Inline Deployment

The following steps occur:

1. The user submits the plain text request (help). The client encrypts this (AaBb) and sends the encrypted
traffic to MedRepo’s Requests department server.
2. LifeIns's router receives the encrypted traffic and routes it to the Requests department server.
3. The managed device does not decrypt this traffic.
The access control policy continues to process the encrypted traffic and allows it, then generates a
connection event after the session ends.
4. The external router receives the traffic and routes it to the Requests department server.
5. The Requests department server receives the encrypted information request (AaBb) and decrypts it to plain
text (help).
6. The Firepower Management Center receives the connection event.

Encrypted Traffic Blocking in an Inline Deployment

For all SMTPS email traffic improperly sent from LifeIns’s underwriting department to MedRepo’s Customer
Service department, the system blocks the traffic during the SSL handshake without further inspection and
logs the connection.

Firepower Management Center Configuration Guide, Version 6.3

1468
 Encrypted Traffic Handling
Encrypted Traffic Inspection with a Private Key in an Inline Deployment

The following steps occur:

1. Having received the request to establish a TLS/SSL handshake from a client’s browser, the Customer
Service department server sends the server certificate (cert) as the next step in the TLS/SSL handshake
to the LifeIns underwriter.
2. MedRepo’s router receives the certificate and routes it to the LifeIns underwriter.
3. The managed device blocks the traffic without further inspection and ends the TCP connection. It generates
a connection event.
4. The internal router does not receive the blocked traffic.
5. The underwriter does not receive the blocked traffic.
6. The Firepower Management Center receives the connection event.

Encrypted Traffic Inspection with a Private Key in an Inline Deployment

For all TLS/SSL-encrypted traffic sent from MedRepo to LifeIns’s underwriting department, the system uses
an uploaded server private key to obtain session keys, then decrypts the traffic and logs the connection.
Legitimate traffic is allowed and reencrypted before being sent to the Underwriting department.

Firepower Management Center Configuration Guide, Version 6.3

1469
 Encrypted Traffic Handling
Encrypted Traffic Inspection with a Private Key in an Inline Deployment

The following steps occur:

1. The user submits the plain text request (stats). The client encrypts this (AaBbC) and sends the encrypted
traffic to the Underwriting department server.
2. The external router receives the traffic and routes it to the Underwriting department server.
3. The managed device uses the session key obtained with the uploaded known private key to decrypt this
traffic to plain text (stats).
The access control policy continues to process the decrypted traffic with the custom intrusion policy and
does not find a spoof attempt. The device passes the encrypted traffic (AaBbC), then generates a connection
event after the session ends.
4. The internal router receives the traffic and routes it to the Underwriting department server.
5. The Underwriting department server receives the encrypted information (AaBbC) and decrypts it to plain
text (stats).
6. The Firepower Management Center receives the connection event with information about the encrypted
and decrypted traffic.

In contrast, any decrypted traffic that is a spoof attempt is dropped. The system logs the connection and the
spoof attempt.

Firepower Management Center Configuration Guide, Version 6.3

1470
 Encrypted Traffic Handling
Encrypted Traffic Inspection with a Re-signed Certificate in an Inline Deployment

The following steps occur:

1. The user submits the plain text request (spoof), altering the traffic to appear to originate from MedRepo,
LLC. The client encrypts this (FfGgH) and sends the encrypted traffic to the Underwriting department
server.
2. The managed device uses the session key obtained with the uploaded known private key to decrypt this
traffic to plain text (spoof).
The access control policy continues to process the decrypted traffic with the custom intrusion policy and
finds a spoof attempt. The device blocks the traffic, then generates an intrusion event. It generates a
connection event after the session ends.
3. The internal router does not receive the blocked traffic.
4. The Underwriting department server does not receive the blocked traffic.
5. The Firepower Management Center receives a connection event with information about the encrypted
and decrypted traffic, and an intrusion event for the spoofing attempt.

Encrypted Traffic Inspection with a Re-signed Certificate in an Inline Deployment

For all TLS/SSL-encrypted traffic sent from the new and junior underwriters to MedRepo’s requests department,
the system uses a re-signed server certificate to obtain session keys, then decrypts the traffic and logs the
connection. Legitimate traffic is allowed and reencrypted before being sent to MedRepo.

Note When decrypting traffic in an inline deployment by re-signing the server certificate, the device acts as a
man-in-the-middle. It creates two TLS/SSL sessions, one between client and managed device, one between
managed device and server. As a result, each session contains different cryptographic session details.

Firepower Management Center Configuration Guide, Version 6.3

1471
 Encrypted Traffic Handling
Encrypted Traffic Inspection with a Re-signed Certificate in an Inline Deployment

The following steps occur:

1. The user submits the plain text request (help). The client encrypts this (AaBb) and sends the encrypted
traffic to the Requests department server.
2. The internal router receives the traffic and routes it to the Requests department server.
3. The managed device uses the session key obtained with a re-signed server certificate and private key to
decrypt this traffic to plain text (help).
The access control policy continues to process the decrypted traffic with the custom intrusion policy and
does not find an improper request. The device reencrypts the traffic (CcDd), allowing it to pass. It generates
a connection event after the session ends.
4. The external router receives the traffic and routes it to the Requests department server.
5. The Requests department server receives the encrypted information (CcDd) and decrypts it to plain text
(help).
6. The Firepower Management Center receives the connection event with information about the encrypted
and decrypted traffic.

Note Traffic encrypted with a re-signed server certificate causes client browsers to warn that the certificate is not
trusted. To avoid this, add the CA certificate to the organization’s domain root trusted certificates store or the
client trusted certificates store.

In contrast, any decrypted traffic that contains information that does not meet regulatory requirements is
dropped. The system logs the connection and the non-conforming information.

Firepower Management Center Configuration Guide, Version 6.3

1472
 Encrypted Traffic Handling
History for TLS/SSL

The following steps occur:

1. The user submits the plain text request (regs), which does not comply with regulatory requirements. The
client encrypts this (EeFf) and sends the encrypted traffic to the Requests department server.
2. The internal router receives the traffic and routes it to the Requests department server.
3. The managed device uses the session key obtained with a re-signed server certificate and private key to
decrypt this traffic to plain text (regs).
The access control policy continues to process the decrypted traffic with the custom intrusion policy and
finds an improper request. The device blocks the traffic, then generates an intrusion event. It generates a
connection event after the session ends.
4. The external router does not receive the blocked traffic.
5. The Requests department server does not receive the blocked traffic.
6. The Firepower Management Center receives a connection event with information about the encrypted
and decrypted traffic, and an intrusion event for the improper request.

History for TLS/SSL

Feature Version Details

Extended Master Secret extension 6.3.0.1 The TLS Extended Master Secret extension is supported for SSL policies;
supported (see RFC 7627) specifically, policies with a rule action of Decrypt - Resign or Decrypt
- Known Key.

Extended Master Secret extension not 6.3 The extension is stripped during ClientHello modification for Decrypt
supported - Resign rules.

TLS/SSL hardware acceleration enabled by 6.3 TLS/SSL hardware acceleration is enabled by default on all supported
default devices but can be disabled if desired.

Firepower Management Center Configuration Guide, Version 6.3

1473
 Encrypted Traffic Handling
History for TLS/SSL

Feature Version Details

Extended Master Secret extension 6.2.3.9 The TLS Extended Master Secret extension is supported for SSL policies;
supported (see RFC 7627) specifically, policies with a rule action of Decrypt - Resign or Decrypt
- Known Key.

Aggressive TLS 1.3 downgrade 6.2.3.7 Using the system support ssl-client-hello-enabled
aggressive-tls13-downgrade {true|false} CLI command, you can
determine the behavior for downgrading TLS 1.3 traffic to TLS 1.2. For
details, see the Command Reference for Firepower Threat Defense.

TLS/SSL hardware acceleration introduced 6.2.3 Certain managed device models perform TLS/SSL encryption and
decryption in hardware, improving performance. By default, the feature
is enabled.
Affected screen: To view the status of TLS/SSL hardware acceleration,
Devices > Device Management > Device, General tab page.

Category and reputation conditions 6.2.2 Access control rules or SSL rules with category/reputation conditions.
supported

SafeSearch supported 6.1.0 • The system displays an HTTP response page for connections
decrypted by the SSL policy, then blocked (or interactively blocked)
either by access control rules or by the access control policy default
action. In these cases, the system encrypts the response page and
sends it at the end of the reencrypted SSL stream.
• SafeSearch filters objectionable content and stops people from
searching adult sites.

Firepower Management Center Configuration Guide, Version 6.3

1474
 CHAPTER 73
Start Creating SSL Policies
The following topics provide an overview of SSL policy creation, configuration, management, and logging.
• SSL Policies Overview, on page 1475
• SSL Policy Default Actions, on page 1476
• Default Handling Options for Undecryptable Traffic, on page 1477
• Manage SSL Policies, on page 1478
• Create Basic SSL Policies, on page 1479
• Set Default Handling for Undecryptable Traffic, on page 1480
• Editing an SSL Policy, on page 1480

SSL Policies Overview

An SSL policy determines how the system handles encrypted traffic on your network. You can configure one
or more SSL policies, associate an SSL policy with an access control policy, then deploy the access control
policy to a managed device. When the device detects a TCP handshake, the access control policy first handles
and inspects the traffic. If it subsequently identifies a TLS/SSL-encrypted session over the TCP connection,
the SSL policy takes over, handling and decrypting the encrypted traffic.

Caution Adding or removing an SSL policy restarts the Snort process when you deploy configuration changes,
temporarily interrupting traffic inspection. Whether traffic drops during this interruption or passes without
further inspection depends on how the target device handles traffic. See Snort® Restart Traffic Behavior, on
page 312 for more information.

The simplest SSL policy, as shown in the following diagram, directs the device where it is deployed to handle
encrypted traffic with a single default action. You can set the default action to block decryptable traffic without
further inspection, or to inspect undecrypted decryptable traffic with access control. The system can then
either allow or block the encrypted traffic. If the device detects undecryptable traffic, it either blocks the traffic
without further inspection or does not decrypt it, inspecting it with access control.

Firepower Management Center Configuration Guide, Version 6.3

1475
 Encrypted Traffic Handling
SSL Policy Default Actions

A more complex SSL policy can handle different types of undecryptable traffic with different actions, control
traffic based on whether a certificate authority (CA) issued or trusts the encryption certificate, and use SSL
rules to exert granular control over encrypted traffic logging and handling. These rules can be simple or
complex, matching and inspecting encrypted traffic using multiple criteria.

Note Because TLS and SSL are often used interchangeably, we use the expression TLS/SSL to indicate that either
protocol is being discussed. The SSL protocol has been deprecated by the IETF in favor of the more secure
TLS protocol, so you can usually interpret TLS/SSL as referring to TLS only.
The exception is SSL policies. Because the FMC configuration option is Policies > Access Control > SSL,
we use the term SSL policies although these policies are used to define rules for TLS and SSL traffic.
For more information about SSL and TLS protocols, see a resource such as SSL vs. TLS - What's the
Difference?.

Related Topics
TLS/SSL Rule Conditions, on page 1491

SSL Policy Default Actions

The default action for an SSL policy determines how the system handles decryptable encrypted traffic that
does not match any non-monitor rule in the policy. When you deploy an SSL policy that does not contain any
TLS/SSL rules, the default action determines how all decryptable traffic on your network is handled. Note
that the system does not perform any kind of inspection on encrypted traffic blocked by the default action.

Table 98: SSL Policy Default Actions

Default Action Effect on Encrypted Traffic

Block Block the TLS/SSL session without further inspection.

Block with reset Block the TLS/SSL session without further inspection and reset
the TCP connection. Choose this option if traffic uses a
connectionless protocol like UDP. In that case, the connectionless
protocol tries to reestablish the connection until it is reset.
This action also displays a connection reset error in the browser
so the user is informed that the connection is blocked.

Do not decrypt Inspect the encrypted traffic with access control.

Firepower Management Center Configuration Guide, Version 6.3

1476
 Encrypted Traffic Handling
Default Handling Options for Undecryptable Traffic

Default Handling Options for Undecryptable Traffic

Table 99: Undecryptable Traffic Types

Type Description Default Action Available Action

Compressed Session The TLS/SSL session applies a Inherit default action Do not decrypt
data compression method.
Block
Block with reset
Inherit default action

SSLv2 Session The session is encrypted with Inherit default action Do not decrypt
SSL version 2.
Block
Note that traffic is decryptable
Block with reset
if the ClientHello message is
SSL 2.0, and the remainder of Inherit default action
the transmitted traffic is SSL
3.0.

Unknown Cipher Suite The system does not recognize Inherit default action Do not decrypt
the cipher suite.
Block
Block with reset
Inherit default action

Unsupported Cipher Suite The system does not support Inherit default action Do not decrypt
decryption based on the detected
Block
cipher suite.
Block with reset
Inherit default action

Session not cached The TLS/SSL session has Inherit default action Do not decrypt
session reuse enabled, the client
Block
and server reestablished the
session with the session Block with reset
identifier, and the system did
Inherit default action
not cache that session identifier.

Handshake Errors An error occurred during Inherit default action Do not decrypt
TLS/SSL handshake
Block
negotiation.
Block with reset
Inherit default action

Decryption Errors An error occurred during traffic Block Block

decryption.
Block with Reset

Firepower Management Center Configuration Guide, Version 6.3

1477
 Encrypted Traffic Handling
Manage SSL Policies

When you first create an SSL policy, logging connections that are handled by the default action is disabled
by default. Because the logging settings for the default action also apply to undecryptable traffic handling,
logging connections handled by the undecryptable traffic actions is disabled by default.
Note that if your browser uses certificate pinning to verify a server certificate, you cannot decrypt this traffic
by re-signing the server certificate. For more information, see TLS/SSL Rule Guidelines and Limitations, on
page 1483.

Manage SSL Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

In the SSL policy editor, you can:

• Configure your policy.
• Add, edit, delete, enable, disable, and organize TLS/SSL rules.
• Add trusted CA certificates.
• Determine the handling for encrypted traffic the system cannot decrypt.
• Log traffic that is handled by the default action and undecryptable traffic actions.

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.

Procedure

Step 1 Choose Policies > Access Control > SSL.

Step 2 Manage SSL policies:
• Associate—To associate an SSL policy with an access control policy, see Associating Other Policies
with Access Control, on page 1365.
• Compare—Click Compare Policies; see Comparing Policies, on page 316.

• Copy—Click the copy icon ( ).

• Create—Click New Policy; see Create Basic SSL Policies, on page 1479.

• Delete—Click the delete icon ( ). If the controls are dimmed, the configuration belongs to an ancestor
domain, or you do not have permission to modify the configuration.
• Deploy—Click Deploy; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1478
 Encrypted Traffic Handling
Create Basic SSL Policies

• Edit—Click the edit icon ( ); see Editing an SSL Policy, on page 1480. If a view icon ( ) appears
instead, the configuration belongs to an ancestor domain, or you do not have permission to modify the
configuration.
• Import/Export—See About Configuration Import/Export, on page 187.

• Report—Click the report icon ( ); see Generating Current Policy Reports, on page 317.

Create Basic SSL Policies

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

To configure an SSL policy, you must give the policy a unique name and specify a default action.

Procedure

Step 1 Choose Policies > Access Control > SSL.

Step 2 Click New Policy.
Step 3 Give the policy a unique Name and, optionally, a Description.
Step 4 Specify the Default Action; see SSL Policy Default Actions, on page 1476.
Step 5 Configure logging options for the default action as described in Logging Connections with a Policy Default
Action, on page 2457.
Step 6 Click Save.

What To Do Next
• Configure rules to add to your SSL policy; see Creating and Modifying TLS/SSL Rules, on page 1486.
• Set the default handling for undecryptable traffic; see Set Default Handling for Undecryptable Traffic,
on page 1480.
• Configure logging options for default handling of undecryptable traffic; see Logging Connections with
a Policy Default Action, on page 2457.
• Associate the SSL policy with an access control policy as described in Associating Other Policies with
Access Control, on page 1365.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1479
 Encrypted Traffic Handling
Set Default Handling for Undecryptable Traffic

Set Default Handling for Undecryptable Traffic

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

You can set undecryptable traffic actions at the SSL policy level to handle certain types of encrypted traffic
the system cannot decrypt or inspect. When you deploy an SSL policy that contains no TLS/SSL rules, the
undecryptable traffic actions determine how all undecryptable encrypted traffic on your network is handled.
Depending on the type of undecryptable traffic, you can choose to:
• Block the connection.
• Block the connection, then reset it. This option is preferrable for connectionless protocols like UDP,
which keep trying to connect until the connection is blocked.
• Inspect the encrypted traffic with access control.
• Inherit the default action from the SSL policy.

Procedure

Step 1 In the SSL policy editor, click the Undecryptable Actions tab.
Step 2 For each field, choose either the SSL policy's default action or another action you want to take on the type of
undecryptable traffic. See Default Handling Options for Undecryptable Traffic, on page 1477 and SSL Policy
Default Actions, on page 1476 for more information.
Step 3 Click Save to save the policy.

What to do next
• Configure default logging for connections handled by the undecryptable traffic actions; see Logging
Connections with a Policy Default Action, on page 2457.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Editing an SSL Policy

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

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

Firepower Management Center Configuration Guide, Version 6.3

1480
Encrypted Traffic Handling
Editing an SSL Policy

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.

Procedure

Step 1 Choose Policies > Access Control > SSL.

Step 2 Click the edit icon ( ) next to the SSL policy you want to configure.

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

Step 3 Configure the SSL policy:

• Describe—If you want to update your SSL policy description, click the Description field and enter the
new description.
• Log—If you want to log connections for undecryptable traffic handling and traffic that does not match
SSL rules, see Logging Connections with a Policy Default Action, on page 2457.
• Rename—If you want to rename your SSL policy, click the Name field and enter the new name.
• Set the default action—If you want to configure how your SSL policy handles traffic that does not match
SSL rules, see SSL Policy Default Actions, on page 1476.
• Set the default action for undecryptable traffic—If you want to configure how your SSL policy handles
undecryptable traffic, see Set Default Handling for Undecryptable Traffic, on page 1480.
• Trust—If you want to add trusted CA certificates to your SSL policy, see Trusting External Certificate
Authorities, on page 1522.

Step 4 Edit the rules in your SSL policy:

• Add—If you want to add a rule, click Add Rule.
• Copy—If you want to copy a rule, right-click a selected rule and choose Copy.
• Cut—If you want to cut a rule, right-click a selected rule and choose Cut.

• Delete—To delete a rule, click the delete icon ( ) next to the rule, then click OK.
• Disable—To disable an enabled rule, right-click a selected rule, choose State, then choose Disable.
• Display—To display the configuration page for a specific rule attribute, click the name, value, or icon
in the column for the condition on the row for the rule. For example, click the name or value in the Source
Networks column to display the Networks page for the selected rule. See Network-Based TLS/SSL Rule
Conditions, on page 1500 for more information.

• Edit—To edit a rule, click the edit icon ( ) next to the rule.
• Enable—To enable a disabled rule, right-click a selected rule, choose State, then choose Enable. Disabled
rules are dimmed and marked (disabled) beneath the rule name.
• Paste—To paste a cut or copied rule, right-click a selected rule and choose Paste Above or Paste Below.

Firepower Management Center Configuration Guide, Version 6.3

1481
 Encrypted Traffic Handling
Editing an SSL Policy

Step 5 Save or discard your configuration:

• To save your changes and continue editing, click Save.
• To discard your changes, click Cancel and, if prompted, click OK.

What to do next
• If the SSL policy is not already associated with an access control policy, associate it as described in
Associating Other Policies with Access Control, on page 1365.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Creating and Modifying TLS/SSL Rules, on page 1486

Firepower Management Center Configuration Guide, Version 6.3

1482
 CHAPTER 74
Get Started with TLS/SSL Rules
The following topics provide an overview of creating, configuring, managing, and troubleshooting TLS/SSL
rules:

Note Because TLS and SSL are often used interchangeably, we use the expression TLS/SSL to indicate that either
protocol is being discussed. The SSL protocol has been deprecated by the IETF in favor of the more secure
TLS protocol, so you can usually interpret TLS/SSL as referring to TLS only.
The exception is SSL policies. Because the FMC configuration option is Policies > Access Control > SSL,
we use the term SSL policies although these policies are used to define rules for TLS and SSL traffic.
For more information about SSL and TLS protocols, see a resource such as SSL vs. TLS - What's the
Difference?.

• TLS/SSL Rules Overview, on page 1483

• TLS/SSL Rule Guidelines and Limitations, on page 1483
• Encrypted Traffic Inspection Configuration, on page 1485
• Creating and Modifying TLS/SSL Rules, on page 1486
• TLS/SSL Rule Conditions, on page 1491
• TLS/SSL Rule Actions, on page 1493
• TLS/SSL Rules Management, on page 1498

TLS/SSL Rules Overview

TLS/SSL rules provide a granular method of handling encrypted traffic across multiple managed devices,
whether blocking the traffic without further inspection, not decrypting the traffic and inspecting it with access
control, or decrypting the traffic for access control analysis.

TLS/SSL Rule Guidelines and Limitations

Keep the following points in mind when setting up your TLS/SSL rules. Properly configuring TLS/SSL rules
is a complex task, but one that is essential to building an effective deployment that handles encrypted traffic.
Many factors influence how you configure rules, including certain application behavior that you cannot control.

Firepower Management Center Configuration Guide, Version 6.3

1483
 Encrypted Traffic Handling
TLS/SSL Rule Guidelines and Limitations

In addition, rules can preempt each other, require additional licenses, or contain invalid configurations.
Thoughtfully configured rules can also reduce the resources required to process network traffic. Creating
overly complex rules and ordering rules the wrong way can adversely affect performance.
For detailed information, see Rule Performance Guidelines, on page 352.
For guidelines related specifically to TLS/SSL hardware acceleration, see TLS/SSL Hardware Acceleration
Guidelines and Limitations, on page 1457.
TLS/SSL pinning
Some applications use a technique referred to as TLS/SSL pinning or certificate pinning, which embeds
the fingerprint of the original server certificate in the application itself. As a result, if you configured a
TLS/SSL rule with a Decrypt - Resign action, when the application receives a resigned certificate from
a managed device, validation fails and the connection is aborted.
Because TLS/SSL pinning is used to avoid man-in-the-middle attacks, there is no way to prevent or work
around it. You have the following options:
• Create a Do Not Decrypt for those applications rule ordered before Decrypt - Resign rules.
• Instruct users to access the applications using a web browser.

For more information about rule ordering, see SSL Rule Order, on page 355.
To determine whether applications are using TLS/SSL pinning, see Troubleshoot TLS/SSL Pinning, on
page 1540.
Users and groups
If you add a group or user to a rule, then change your realm settings to exclude that group or user, the
rule has no effect. (The same applies to disabling the realm.) For more information about realms, see
Create a Realm, on page 2092.
Use decryption only on devices handling encrypted traffic
Set up Decrypt - Resign or Decrypt - Known Key rules only if your managed device handles encrypted
traffic. Decryption rules require processing overhead that can impact performance.
Zone conditions and passive interfaces
If you create a Decrypt - Resign rule, and later add a security zone with passive interfaces to a zone
condition, the system displays a warning icon next to the rule. Because you cannot decrypt traffic by
re-signing a certificate in a passive deployment, the rule has no effect until you remove the passive
interfaces from the rule or change the rule action.
Categories in TLS/SSL rules
If your SSL policy has a Decrypt - Resign action but web sites are not being decrypted, check the
Category tab page on rules associated with that policy.
In some cases, a web site redirects to another site for authentication or other purposes and the redirected
site might have a different URL categorization than the site you're trying to decrypt. For example,
gmail.com (Web based email category) redirects to accounts.gmail.com (Internet Portals
category) for authentication. Be sure to include all relevant categories in the SSL rule.
Query for URLs not in the local database
If you create a Decrypt - Resign rule and users browse to a web site whose category and reputation are
not in the local database, data might not be decrypted. Some web sites are not categorized in the local
database and, if not, data from those web sites is not decrypted by default.

Firepower Management Center Configuration Guide, Version 6.3

1484
 Encrypted Traffic Handling
Encrypted Traffic Inspection Configuration

You can control this behavior with the setting System > Integration > Cisco CSI , and check Query
Cisco CSI for Unknown URLs.
For more information about this option, see Cisco Security Intelligence Clouds, on page 1562.
TLS heartbeat
Some applications use the TLS heartbeat extension to the Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS) protocols defined by RFC6520. TLS heartbeat provides a way to
confirm the connection is still alive—either the client or server sends a specified number of bytes of data
and requests the other party echo the response. If this is successful, encrypted data is sent.
If your managed device does not support TLS/SSL hardware acceleration or if is disabled, you can
configure a Max Heartbeat Length in a Network Analysis Policy (NAP) to determine how to handle
TLS heartbeats. For more information, see The SSL Preprocessor, on page 1931.
Related Topics
Rule and Other Policy Warnings, on page 351
Rule Performance Guidelines, on page 352
Troubleshoot TLS/SSL Oversubscription, on page 1536
Troubleshoot TLS Heartbeat, on page 1538
Troubleshoot TLS/SSL Pinning, on page 1540

Encrypted Traffic Inspection Configuration

You must create reusable public key infrastructure (PKI) objects to control encrypted traffic based on encrypted
session characteristics and decrypt encrypted traffic. You can add this information on the fly when uploading
trusted certificate authority (CA) certificates to the SSL policy and creating SSL rule conditions, creating the
associated object in the process. However, configuring these objects ahead of time reduces the chance of
improper object creation.

Decrypting Encrypted Traffic with Certificates and Paired Keys

The system can decrypt incoming encrypted traffic if you configure an internal certificate object by uploading
the server certificate and private key used to encrypt the session. If you reference that object in an SSL rule
with an action of Decrypt - Known Key and traffic matches that rule, the system uses the uploaded private
key to decrypt the session.
The system can also decrypt outgoing traffic if you configure an internal CA object by uploading a CA
certificate and private key. If you reference that object in a TLS/SSL rule with an action of Decrypt - Resign
and traffic matches that rule, the system re-signs the server certificate passed to the client browser, then acts
as a man-in-the-middle to decrypt the session.You can optionally replace the self-signed certificate key only
and not the entire certificate, in which case users see a self-signed certificate key notice in the browser.

Controlling Traffic Based on Encrypted Session Characteristics

The system can control encrypted traffic based on the cipher suite or server certificate used to negotiate the
session. You can configure one of several different reusable objects and reference the object in a TLS/SSL
rule condition to match traffic. The following table describes the different types of reusable objects you can
configure:

Firepower Management Center Configuration Guide, Version 6.3

1485
 Encrypted Traffic Handling
Creating and Modifying TLS/SSL Rules

If you configure... You can control encrypted traffic based on whether...

A cipher suite list containing one or more cipher suites The cipher suite used to negotiate the encrypted session matches
a cipher suite in the cipher suite list

A trusted CA object by uploading a CA certificate your The trusted CA trusts the server certificate used to encrypt the
organization trusts session, whether:
• The CA issued the certificate directly
• The CA issued a certificate to an intermediate CA that issued
the server certificate

An external certificate object by uploading a server certificate The server certificate used to encrypt the session matches the
uploaded server certificate

A distinguished name object containing a certificate subject or The subject or issuer common name, country, organization, or
issuer distinguished name organizational unit on the certificate used to encrypt the session
matches the configured distinguished name

Related Topics
Cipher Suite Lists, on page 412
Distinguished Name Objects, on page 413
PKI Objects, on page 415

Creating and Modifying TLS/SSL Rules

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 Log in to the Firepower Management Center.

Step 2 Click Policies > Access Control > SSL.

Step 3 Click the edit icon ( ) next to the SSL policy.

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

Step 4 You have the following choices:

• To add a new rule, click Add Rule.
• To edit an existing rule, click the edit icon ( ).

Step 5 Enter a Name for the rule.

Step 6 Specify whether the rule is Enabled.

Firepower Management Center Configuration Guide, Version 6.3

1486
 Encrypted Traffic Handling
Adding a TLS/SSL Rule to a Rule Category

Step 7 Specify the rule position; see TLS/SSL Rule Order Evaluation.
Step 8 Click a rule Action; see Configuring TLS/SSL Rule Actions, on page 1496.
Step 9 Configure the rule’s conditions; see TLS/SSL Rule Condition Types, on page 1491.
Step 10 Click Save.
If the following error displays, see Verify TLS/SSL Cipher Suites, on page 1542: Traffic cannot match this
rule; none of your selected cipher suites contain a signature algorithm that the resigning CA's signature
algorithm.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Adding a TLS/SSL Rule to a Rule Category

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL rule editor, from the Insert drop-down list, select Into Category, then select the category you
want to use.
Step 2 Click Save.
Tip When you save the rule, it is placed last in that category.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Positioning a TLS/SSL Rule by Number

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Firepower Management Center Configuration Guide, Version 6.3

1487
 Encrypted Traffic Handling
TLS/SSL Rule Search

Procedure

Step 1 In the SSL rule editor, from the Insert drop-down list, select above rule or below rule, then type the appropriate
rule number.
Step 2 Click Save.
Tip When you save the rule, it is placed where you specified.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

TLS/SSL Rule Search

You can search the list of TLS/SSL rules for matching values using an alphanumeric string, including spaces
and printable, special characters. The search inspects the rule name and any rule condition you have added to
the rule. For rule conditions, the search matches any name or value you can add for each condition type (zone,
network, application, and so on). This includes individual object names or values, group object names,
individual object names or values within a group, and literal values.
You can use complete or partial search strings. The column for matching values is highlighted for each
matching rule. For example, if you search on all or part of the string 100Bao, at a minimum, the Applications
column is highlighted for each rule where you have added the 100Bao application. If you also have a rule
named 100Bao, both the Name and Applications columns are highlighted.
You can navigate to each previous or next matching rule. A status message displays the current match and
the total number of matches.
Matches may occur on any page of a multi-page rule list. When the first match is not on the first page, the
page where the first match occurs is displayed. Selecting the next match when you are at the last match takes
you to the first match, and selecting the previous match when you are at the first match takes you to the last
match.

Searching TLS/SSL Rules

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL policy editor, click the Search Rules prompt, type a search string, then press Enter.
Tip Columns for rules with matching values are highlighted, with differentiated highlighting for the
indicated (first) match.

Firepower Management Center Configuration Guide, Version 6.3

1488
 Encrypted Traffic Handling
Enabling and Disabling TLS/SSL Rules

Step 2 Find the rules you are interested in:

• To navigate between matching rules, click the next-match ( ) or previous-match ( ) icon.

• To refresh the page and clear the search string and any highlighting, click the clear icon ( ).

Enabling and Disabling TLS/SSL Rules

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

When you create a TLS/SSL rule, it is enabled by default. If you disable a rule, the system does not use it to
evaluate network traffic and stops generating warnings and errors for that rule. When viewing the list of rules
in an SSL policy, disabled rules are grayed out, although you can still modify them. Note that you can also
enable or disable a TLS/SSL rule using the rule editor.

Procedure

Step 1 In the SSL policy editor, right-click a rule and choose a rule state.
Step 2 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Moving a TLS/SSL Rule

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL policy editor, select the rules by clicking in a blank area for each rule.
Step 2 Right-click the rule and select Cut.
Step 3 Right-click a blank area for a rule next to where you want to paste the cut rules and select Paste above or
Paste below.
Tip You cannot copy and paste TLS/SSL rules between two different SSL policies.

Firepower Management Center Configuration Guide, Version 6.3

1489
 Encrypted Traffic Handling
Adding a New TLS/SSL Rule Category

Step 4 Click Save.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Adding a New TLS/SSL Rule Category

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

You can create custom categories between the Standard Rules and Root Rules categories to further organize
your rules without having to create additional policies. You can rename and delete categories that you add.
You cannot move these categories, but you can move rules into, within, and out of them.

Procedure

Step 1 In the policy editor, click Add Category.

Tip If your policy already contains rules, you can click a blank area in the row for an existing rule to
set the position of the new category before you add it. You can also right-click an existing rule and
select Insert new category.

Step 2 Type a Name.

Step 3 You have the following choices:
• Select above Category from the first Insert drop-down list, then select the category above which you
want to position the rule from the second drop-down list.
• Select below rule from the drop-down list, then enter an existing rule number. This option is valid only
when at least one rule exists in the policy.
• Select above rule from the drop-down list, then, enter an existing rule number. This option is valid only
when at least one rule exists in the policy.

Step 4 Click OK.

Tip Rules in a category you delete are added to the category above.

Step 5 Click Save.

Firepower Management Center Configuration Guide, Version 6.3

1490
 Encrypted Traffic Handling
TLS/SSL Rule Conditions

TLS/SSL Rule Conditions

An SSL rule’s conditions identify the type of encrypted traffic the rule handles. Conditions can be simple or
complex, and you can specify more than one condition type per rule. Only if traffic meets all the conditions
in a rule does the rule apply to the traffic.
If you do not configure a particular condition for a rule, the system does not match traffic based on that
criterion. For example, a rule with a certificate condition but no version condition evaluates traffic based on
the server certificate used to negotiate the session, regardless of the session SSL or TLS version.
Every TLS/SSL rule has an associated action that determines the following for matching encrypted traffic:
• Handling: Most importantly, the rule action governs whether the system will monitor, trust, block, or
decrypt encrypted traffic that matches the rule’s conditions
• Logging: The rule action determines when and how you can log details about matching encrypted traffic.

Your TLS/SSL inspection configuration handles, inspects, and logs decrypted traffic:
• The SSL policy’s undecryptable actions handle traffic that the system cannot decrypt.
• The policy’s default action handles traffic that does not meet the condition of any non-Monitor TLS/SSL
rule.

You can log a connection event when the system blocks or trusts an encrypted session. You can also force
the system to log connections that it decrypts for further evaluation by access control rules, regardless of how
the system later handles or inspects the traffic. Connection logs for encrypted sessions contain details about
the encryption, such as the certificate used to encrypt that session. You can log only end-of-connection events,
however:
• For blocked connections (Block, Block with reset), the system immediately ends the sessions and generates
an event
• For trusted connections (Do not decrypt), the system generates an event when the session ends

TLS/SSL Rule Condition Types

When you add or edit an SSL rule, use the tabs on the left side of the lower portion of the rule editor to add
and edit rule conditions.

Table 100: TLS/SSL Rule Condition Types

This Condition... Matches Encrypted Traffic... Details

Zones Entering or leaving a device via an interface A security zone is a logical grouping of one
in a specific security zone or more interfaces according to your
deployment and security policies. Interfaces
in a zone may be located across multiple
devices.
Note You cannot decrypt traffic on an
inline or tap mode interface.

Firepower Management Center Configuration Guide, Version 6.3

1491
 Encrypted Traffic Handling
TLS/SSL Rule Condition Types

This Condition... Matches Encrypted Traffic... Details

Networks By its source or destination IP address, You can explicitly specify IP addresses.
country, or continent The geolocation feature also allows you to
control traffic based on its source or
destination country or continent.

VLAN Tags Tagged by VLAN The system uses the innermost VLAN tag
to identify a packet by VLAN.

Ports By its source or destination port You can control encrypted traffic based on
the TCP port.

Users By the user involved in the session You can control encrypted traffic based on
the LDAP user logged into a host involved
in an encrypted, monitored session. You
can control traffic based on individual users
or groups retrieved from a Microsoft Active
Directory server.

Applications By the application detected in a session You can control access to individual
applications in encrypted sessions, or filter
access according to basic characteristics:
type, risk, business relevance, and
categories.

Categories By the URL requested in the session, based You can limit the websites that users on
on the certificate subject distinguished your network can access based on the
name URL’s general classification and risk level.

Distinguished Names By the subject, Subject Alternative Name You can control encrypted traffic based on
(SAN), or issuer distinguished name of the the CA that issued a server certificate, or
server certificate used to negotiate the the server certificate holder.
encrypted session

Certificates By the server certificate used to negotiate You can control encrypted traffic based on
the encrypted session the server certificate passed to the user’s
browser in order to negotiate the encrypted
session.

Certificate Status By properties of the server certificate used You can control encrypted traffic based on
to negotiate the encrypted session a server certificate’s status.

Cipher Suites By the cipher suite used to negotiate the You can control encrypted traffic based on
encrypted session the cipher suite selected by the server to
negotiate the encrypted session.

Versions By the version of SSL or TLS used to You can control encrypted traffic based on
encrypt the session the version of SSL or TLS used to encrypt
the session.

Related Topics
Network-Based TLS/SSL Rule Conditions, on page 1500

Firepower Management Center Configuration Guide, Version 6.3

1492
 Encrypted Traffic Handling
TLS/SSL Rule Actions

User-Based TLS/SSL Rule Conditions, on page 1507

Reputation-Based URL Blocking in Encrypted Traffic, on page 1513
Server Certificate-Based TLS/SSL Rule Conditions, on page 1514
ClientHello Message Handling, on page 1453

TLS/SSL Rule Actions

TLS/SSL Rule Monitor Action
The Monitor action does not affect encrypted traffic flow; matching traffic is neither immediately permitted
nor denied. Rather, traffic is matched against additional rules, if present, to determine whether to trust, block,
or decrypt it. The first non-Monitor rule matched determines traffic flow and any further inspection. If there
are no additional matching rules, the system uses the default action.
Because the primary purpose of Monitor rules is to track network traffic, the system automatically logs end-of
connection events for monitored traffic to the Firepower Management Center database, regardless of the
logging configuration of the rule or default action that later handles the connection.

TLS/SSL Rule Do Not Decrypt Action

The Do Not Decrypt action passes encrypted traffic for evaluation by the access control policy’s rules and
default action. Because some access control rule conditions require unencrypted traffic, this traffic may match
fewer rules. The system cannot perform deep inspection on encrypted traffic, such as intrusion or file inspection.
Typical reasons for a Do Not Decrypt rule action include:
• When decrypting TLS/SSL traffic is prohibited by law.
• Sites you know you can trust.
• Sites you can disrupt by inspecting traffic (such as Windows Update).
• To view the values of TLS/SSL fields using connection events. (You do not need to decrypt traffic to
view connection event fields.) For more information, see Requirements for Populating Connection Event
Fields, on page 2478.

For more information, see Default Handling Options for Undecryptable Traffic, on page 1477

TLS/SSL Rule Blocking Actions

The Block and Block with reset actions are analogous to the access control rule actions Block and Block
with reset. These actions prevent the client and server from establishing the TLS/SSL-encrypted session and
passing encrypted traffic. Block with reset rules also reset the connection.
Note that the system does not display the configured response page for blocked encrypted traffic. Instead,
users requesting prohibited URLs have their connection either reset or time out.

Firepower Management Center Configuration Guide, Version 6.3

1493
 Encrypted Traffic Handling
TLS/SSL Rule Decrypt Actions

Tip Note that you cannot use the Block or Block with reset action in a passive or inline (tap mode) deployment,
as the device does not directly inspect the traffic. If you create a rule with the Block or Block with reset action
that contains passive or inline (tap mode) interfaces within a security zone condition, the policy editor displays
a warning icon ( ) next to the rule.

Related Topics
About HTTP Response Pages, on page 1401

TLS/SSL Rule Decrypt Actions

The Decrypt - Known Key and Decrypt - Resign actions decrypt encrypted traffic. The system inspects
decrypted traffic with access control. Access control rules handle decrypted and unencrypted traffic identically
— you can inspect it for discovery data as well as detect and block intrusions, prohibited files, and malware.
The system reencrypts allowed traffic before passing it to its destination.
We recommend you use a certificate from a trusted Certificate Authority (CA) to decrypt traffic. This prevents
Invalid Issuer from being displayed in the SSL Certificate Status column in connection events.
For more information about adding trusted objects, see Trusted Certificate Authority Objects, on page 421.

TLS/SSL Rule Decryption Mechanism and Guidelines

When you configure the Decrypt - Known Key action, you can associate one or more server certificates and
paired private keys with the action. If traffic matches the rule, and the certificate used to encrypt the traffic
matches the certificate associated with the action, the system uses the appropriate private key to obtain the
session encryption and decryption keys. Because you must have access to the private key, this action is best
suited to decrypt traffic incoming to servers your organization controls.
Similarly, you can associate one Certificate Authority certificate and private key with the Decrypt - Resign
action. If traffic matches this rule, the system re-signs the server certificate with the CA certificate, then acts
as a man-in-the-middle. It creates two TLS/SSL sessions, one between client and managed device, one between
managed device and server. Each session contains different cryptographic session details, and allows the
system to decrypt and reencrypt traffic. This action is more suited for outgoing traffic, as you replace the
certificate’s private key with one you control to obtain the session keys.
Re-signing a server certificate involves either replacing the certificate’s public key with a CA certificate public
key, or replacing the entire certificate. Normally, if you replace an entire server certificate, the client browser
warns the certificate is not signed by a trusted authority when establishing the TLS/SSL connection. However,
if your client’s browser trusts the CA in the policy, the browser does not warn that the certificate is not trusted.
If the original server certificate is self-signed, the system replaces the entire certificate, and trusts the re-signing
CA, but the user’s browser does not warn that the certificate is self-signed. In this case, replacing only the
server certificate public key causes the client browser does warn that the certficate is self-signed.
If you configure a rule with the Decrypt - Resign action, the rule matches traffic based on the referenced
internal CA certificate’s signature algorithm type, in addition to any configured rule conditions. Because you
associate one CA certificate with a Decrypt - Resign action, you cannot create a TLS/SSL rule that decrypts
multiple types of outgoing traffic encrypted with different signature algorithms. In addition, any external
certificate objects and cipher suites you add to the rule must match the associated CA certificate encryption
algorithm type. You can optionally replace the self-signed certificate key only and not the entire certificate,
in which case users see a self-signed certificate key notice in the browser.

Firepower Management Center Configuration Guide, Version 6.3

1494
Encrypted Traffic Handling
TLS/SSL Rule Decryption Mechanism and Guidelines

For example, outgoing traffic encrypted with an elliptic curve (EC) algorithm matches a Decrypt - Resign
rule only if the action references an EC-based CA certificate; you must add EC-based external certificates
and cipher suites to the rule to create certificate and cipher suite rule conditions. Similarly, a Decrypt - Resign
rule that references an RSA-based CA certificate matches only outgoing traffic encrypted with an RSA
algorithm; outgoing traffic encrypted with an EC algorithm does not match the rule, even if all other configured
rule conditions match.
Note the following:
• You cannot use the Decrypt - Known Key action in a passive deployment if the cipher suite used to
establish the TLS/SSL connection applies either the Diffie-Hellman ephemeral (DHE) or the elliptic
curve Diffie-Hellman ephemeral (ECDHE) key exchange algorithm. If your SSL policy targets a device
with passive or inline (tap mode) interfaces, and contains a Decrypt - Known Key rule with a cipher
suite condition containing either a DHE or an ECDHE cipher suite, the system displays an information
icon ( ) next to the rule. If you later add a zone condition to the TLS/SSL rule that contains passive or
inline (tap mode) interfaces, the system displays a warning icon ( ).
• You cannot use the Decrypt - Resign action in a passive or inline (tap mode) deployment because the
device does not directly inspect traffic. If you create a rule with the Decrypt - Resign action that contains
passive or inline (tap mode) interfaces within a security zone, the policy editor displays a warning icon
( ) next to the rule.
If your SSL policy targets a device with passive or inline (tap mode) interfaces, and contains a Decrypt
- Resign rule, the system displays an information icon ( ) next to the rule. If you later add a zone
condition to the TLS/SSL rule that contains passive or inline (tap mode) interfaces, the system displays
a warning icon ( ). If you deploy an SSL policy that contains a Decrypt - Resign rule to a device with
passive or inline (tap mode) interfaces, any TLS/SSL sessions that match the rule fail.
The following error is displayed if you attempt to save a TLS/SSL rule with a cipher suite that does not
match the certificate. To resolve the issue, see Verify TLS/SSL Cipher Suites, on page 1542.
Traffic cannot match this rule; none of your selected cipher suites contain a
signature algorithm that the resigning CA's signature algorithm

• If the client does not trust the CA used to re-sign the server certificate, it warns the user that the certificate
should not be trusted. To prevent this, import the CA certificate into the client trusted CA store.
Alternatively, if your organization has a private PKI, you can issue an intermediate CA certificate signed
by the root CA which is automatically trusted by all clients in the organization, then upload that CA
certificate to the device.
• You can add an anonymous cipher suite to the Cipher Suite condition in a TLS/SSL rule, but keep in
mind:
• The system automatically strips anonymous cipher suites during ClientHello processing. For the
system to use the rule, you must also configure your TLS/SSL rules in an order that prevents
ClientHello processing. For more information, see SSL Rule Order, on page 355.
• You cannot use the Decrypt - Resign or Decrypt - Known Key action in the rule, because the
system cannot decrypt traffic encrypted with an anonymous cipher suite.

• The system cannot decrypt traffic if an HTTP proxy is positioned between a client and your managed
device, and the client and server establish a tunneled TLS/SSL connection using the CONNECT HTTP
method. The Handshake Errors undecryptable action determines how the system handles this traffic.

Firepower Management Center Configuration Guide, Version 6.3

1495
 Encrypted Traffic Handling
Configuring TLS/SSL Rule Actions

• The system cannot decrypt traffic in the captive portal authentication connection between a captive portal
user's web browser and the captive portal daemon on the managed device.
• You cannot match on Distinguished Name or Certificate conditions when creating a TLS/SSL rule
with a Decrypt - Known Key action. The assumption is that if this rule matches traffic, the certificate,
subject DN, and issuer DN already match the certificate associated with the rule.
• If you create an internal CA object and choose to generate a certificate signing request (CSR), you cannot
use this CA for a Decrypt - Resign action until you upload the signed certificate to the object.
• If you configure a rule with the Decrypt - Resign action, and mismatch signature algorithm type for one
or more external certificate objects or cipher suites, the policy editor displays an information icon ( )
next to the rule. If you mismatch signature algorithm type for all external certificate objects, or all cipher
suites, the policy displays a warning icon ( ) next to the rule, and you cannot deploy the access control
policy associated with the SSL policy.
• If the customer's browser uses certificate pinning to verify a server certificate, you cannot decrypt this
traffic by re-signing the server certificate. To allow this traffic, configure a TLS/SSL rule with the Do
not decrypt action to match the server certificate common name or distinguished name.
• If decrypted traffic matches an access control rule with an action of Interactive Block or Interactive
Block with reset, the system displays a response page.
• If you enable the Normalize Excess Payload option in the inline normalization preprocessor, when the
preprocessor normalizes decrypted traffic, it might drop a packet and replace it with a trimmed packet.
This does not end the TLS/SSL session. If the traffic is allowed, the trimmed packet is encrypted as part
of the TLS/SSL session.

Related Topics
PKI Objects, on page 415

Configuring TLS/SSL Rule Actions

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL policy editor, you have the following options:
• To add a new rule, click Add Rule.

• To edit an existing rule, click the edit icon ( ).

Step 2 Select a rule action from the Action drop-down list.

• To block encrypted traffic, select Block.
• To block encrypted traffic and reset the connection, select Block with reset.

Firepower Management Center Configuration Guide, Version 6.3

1496
 Encrypted Traffic Handling
Configuring a Decrypt - Resign Action

• To decrypt incoming traffic, see Configuring a Decrypt - Known Key Action, on page 1498 for more
information.
• To decrypt outgoing traffic, see Configuring a Decrypt - Resign Action, on page 1497 for more information.
• To log encrypted traffic, select Monitor.
• To not decrypt encrypted traffic, select Do not decrypt.

Step 3 Click Add.

What to do next
• Configure rule conditions, as described in Network-Based TLS/SSL Rule Conditions, on page 1500,
User-Based TLS/SSL Rule Conditions, on page 1507, Reputation-Based TLS/SSL Rule Conditions, on
page 1507, and Server Certificate-Based TLS/SSL Rule Conditions, on page 1514.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Configuring a Decrypt - Resign Action

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL rule editor, select Decrypt - Resign from the Action list.
Step 2 Select an internal CA certificate object from the list.
Step 3 To replace only the certificate public key instead of the entire certificate, you must check Replace Key Only
. Because you're replacing the public key only, users get a self-signed certificate notice in the browser.
Step 4 Click Add.
Step 5 Optional. To use a Trusted CA certificate in your SSL policy so you can avoid Invalid Issuer in the SSL
Certificate Status column in connection events, add the certificate to the policy:
a) In the SSL policy editor page, click the Trusted CA Certificates tab.
b) Add the CA certificate corresponding to your known key to the SSL policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1497
 Encrypted Traffic Handling
Configuring a Decrypt - Known Key Action

Configuring a Decrypt - Known Key Action

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL rule editor, select Decrypt - Known Key from the Action drop-down list.
Step 2 Click the Click to select decryption certs field.
Step 3 Select one or more internal certificate objects in the Available Certificates list, then click Add to Rule.
Step 4 Click OK.
Step 5 Click Add.
Step 6 Optional. To use a Trusted CA certificate in your SSL policy so you can avoid Invalid Issuer in the SSL
Certificate Status column in connection events, add the certificate to the policy:
a) In the SSL policy editor page, click the Trusted CA Certificates tab.
b) Add the CA certificate corresponding to your known key to the SSL policy.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

TLS/SSL Rules Management

The Rules tab page of the SSL policy editor allows you to add, edit, search, move, enable, disable, delete,
and otherwise manage TLS/SSL rules in your policy.

Firepower Management Center Configuration Guide, Version 6.3

1498
 CHAPTER 75
Decryption Tuning Using TLS/SSL Rules
The following topics provide an overview of how to configure TLS/SSL rule conditions:
• TLS/SSL Rule Conditions Overview, on page 1499
• Network-Based TLS/SSL Rule Conditions, on page 1500
• User-Based TLS/SSL Rule Conditions, on page 1507
• Reputation-Based TLS/SSL Rule Conditions, on page 1507
• Server Certificate-Based TLS/SSL Rule Conditions, on page 1514

TLS/SSL Rule Conditions Overview

A basic TLS/SSL rule applies its rule action to all encrypted traffic inspected by the device. To better control
and decrypt encrypted traffic, you can configure rule conditions to handle and log specific types of traffic.
Each TLS/SSL rule can contain 0, 1, or more rule conditions; a rule matches traffic only if the traffic matches
every condition in that TLS/SSL rule.

Note When traffic matches a rule, the device applies the configured rule action to the traffic. When the connection
ends, the device logs the traffic if configured to do so.

Each rule condition allows you to specify one or more properties of traffic you want to match against; these
properties include details of:
• The flow of traffic, including the security zone through which it travels, IP address and port, country of
origin or destination, and origin or destination VLAN.
• The user associated with a detected IP address.
• The traffic payload, including the application detected in the traffic.
• The connection encryption, including the TLS/SSL protocol version and cipher suite and server certificate
used to encrypt the connection.
• The category and reputation of the URL specified in the server certificate’s distinguished name..

Firepower Management Center Configuration Guide, Version 6.3

1499
 Encrypted Traffic Handling
Network-Based TLS/SSL Rule Conditions

Network-Based TLS/SSL Rule Conditions

TLS/SSL rules in SSL policies exert granular control over encrypted traffic logging and handling.
Network-based conditions allow you to manage which encrypted traffic can traverse your network, using one
or more of the following criteria:
• Zone conditions in TLS/SSL rules allow you to control encrypted traffic by its source and destination
security zones. A security zone is a grouping of one or more interfaces, which might be located across
multiple devices.
• Network conditions in TLS/SSL rules allow you to control and decrypt encrypted traffic by its source
and destination IP address. You can either explicitly specify the source and destination IP addresses for
the encrypted traffic you want to control, or use the geolocation feature, which associates IP addresses
with geographical locations, to control encrypted traffic based on its source or destination country or
continent.
• VLAN conditions in TLS/SSL rules allow you to control VLAN-tagged traffic. The system uses the
innermost VLAN tag to identify a packet by VLAN.
• Port conditions in TLS/SSL rules allow you to control encrypted traffic by its source and destination
TCP port.

You can combine network-based conditions with each other and with other types of conditions to create a
TLS/SSL rule. These TLS/SSL rules can be simple or complex, matching and inspecting traffic using multiple
conditions.
Related Topics
Firepower System IP Address Conventions, on page 15

Network Zone TLS/SSL Rule Conditions

You can add a maximum of 50 zones to each of the Sources Zones and Destination Zones in a single zone
condition:
• To match encrypted traffic leaving the device from an interface in the zone, add that zone to the
Destination Zones.
Because devices deployed passively do not transmit traffic, you cannot use a zone comprised of passive
interfaces in a Destination Zone condition.

• To match encrypted traffic entering the device from an interface in the zone, add that zone to the Source
Zones.

If you add both source and destination zone conditions to a rule, matching traffic must originate from one of
the specified source zones and egress through one of the destination zones.
Note that just as all interfaces in a zone must be of the same type (all inline, all passive, all switched, or all
routed), all zones used in a zone condition for a TLS/SSL rule must be of the same type. That is, you cannot
write a single rule that matches encrypted traffic to or from zones of different types.

Firepower Management Center Configuration Guide, Version 6.3

1500
 Encrypted Traffic Handling
Controlling Encrypted Traffic by Network Zone

Note You can create a TLS/SSL rule condition to decrypt traffic in a security zone that includes an inline or tap
mode interface but traffic will not be decrypted on those interfaces.

Warning icons indicate invalid configurations, such as zones that contain no interfaces. For details, hover
your pointer over the icon.

Controlling Encrypted Traffic by Network Zone

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL rule editor, select the Zones tab.

Step 2 Find the zones you want to add from the Available Zones. To search for zones to add, click the Search by
name prompt above the Available Zones list, then type a zone name. The list updates as you type to display
matching zones.
Step 3 Click to select a zone. To select all zones, right-click and then select Select All.
Step 4 Click Add to Source or Add to Destination.
Tip You can also drag and drop selected zones.

Step 5 Save or continue editing the rule.

Example
For example, you could deploy additional identically configured devices—managed by the same
Firepower Management Center—to protect similar resources in several different locations. Like the
first device, each of these devices protects the assets in an Internal security zone.

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.

In this deployment, you may decide that although you want these hosts to have unrestricted access
to the Internet, you nevertheless want to protect them by decrypting and inspecting incoming encrypted
traffic.
To accomplish this, configure a TLS/SSL rule with a zone condition where the Destination Zone
is set to Internal. This simple SSL rule matches traffic that leaves the device from any interface in
the Internal zone.

Firepower Management Center Configuration Guide, Version 6.3

1501
 Encrypted Traffic Handling
Network or Geolocation TLS/SSL Rule Conditions

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Interface Objects: Interface Groups and Security Zones, on page 379

Network or Geolocation TLS/SSL Rule Conditions

When you build a network-based TLS/SSL rule condition, you can manually specify IP address and geographical
locations. Alternately, you can configure network conditions with network and geolocation objects, which
are reusable and associate a name with one or more IP addresses, address blocks, countries, continents, and
so on.

Note If you want to write rules to control traffic by geographical location, to ensure you are using up-to-date
geolocation data to filter your traffic, Cisco strongly recommends you regularly update the geolocation
database (GeoDB) on your Firepower Management Center.

You can add a maximum of 50 items to each of the Source Networks and Destination Networks in a single
network condition, and you can mix network and geolocation-based configurations:
• To match encrypted traffic from an IP address or geographical location, configure the Source Networks.
• To match encrypted traffic to an IP address or geographical location, configure the Destination Networks.

If you add both source and destination network conditions to a rule, matching encrypted traffic must originate
from one of the specified IP addresses and be destined for one of the destination IP addresses.
When building a network condition, warning icons indicate invalid configurations. For details, hover your
pointer over the icon.
Related Topics
Firepower System IP Address Conventions, on page 15

Controlling Encrypted Traffic by Network or Geolocation

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Before you begin

• Update the geolocation database (GeoDB) on your Firepower Management Center as described in Update
the Geolocation Database (GeoDB), on page 148.

Firepower Management Center Configuration Guide, Version 6.3

1502
Encrypted Traffic Handling
Controlling Encrypted Traffic by Network or Geolocation

Procedure

Step 1 In the SSL rule editor, select the Networks tab.

Step 2 Find the networks you want to add from the Available Networks, as follows:
• Click the Networks tab to display network objects and groups to add; click the Geolocation tab to display
geolocation objects.

• To add a network object on the fly, which you can then add to the condition, click the add icon ( )
above the Available Networks list.
• To search for network or geolocation objects to add, select the appropriate tab, click the Search by name
or value prompt above the Available Networks list, then type an object name or the value of one of the
object’s components. The list updates as you type to display matching objects.

Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Source or Add to Destination.
Tip You can also drag and drop selected objects.

Step 5 Add any source or destination IP addresses or address blocks that you want to specify manually. Click the
Enter an IP address prompt below the Source Networks or Destination Networks list; then type an IP
address or address block and click Add.
Step 6 Save or continue editing the rule.

Example
The following graphic shows the network condition for a TLS/SSL rule that blocks encrypted
connections originating from your internal network and attempting to access resources either in the
Cayman Islands or an offshore holding corporation server at 182.16.0.3.

The example manually specifies the offshore holding corporation’s server IP address, and uses a
system-provided Cayman Islands geolocation object to represent Cayman Island IP addresses.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Network Objects, on page 371
Firepower System IP Address Conventions, on page 15

Firepower Management Center Configuration Guide, Version 6.3

1503
 Encrypted Traffic Handling
VLAN TLS/SSL Rule Conditions

VLAN TLS/SSL Rule Conditions

When you build a VLAN-based TLS/SSL rule condition, you can manually specify a VLAN tag from 1 to
4094. Alternately, you can configure VLAN conditions with VLAN tag objects, which are reusable and
associate a name with one or more VLAN tags.

Tip After you create a VLAN tag object, you can use it not only to build TLS/SSL rules, but also to represent
VLAN tags in various other places in the system’s web interface. You can create VLAN tag objects either
using the object manager or on-the-fly while you are configuring access control rules.

You can add a maximum of 50 items to the Selected VLAN Tags in a single VLAN tag condition. When
building a VLAN tag condition, warning icons indicate invalid configurations. For details, hover your pointer
over the icon.

Controlling Encrypted VLAN Traffic

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL rule editor, select the VLAN Tags tab.
Step 2 Find the VLANs you want to add from the Available VLAN Tags, as follows:

• To add a VLAN tag object on the fly, which you can then add to the condition, click the add icon ( )
above the Available VLAN Tags list.
• To search for VLAN tag objects and groups to add, click the Search by name or value prompt above
the Available VLAN Tags list, then type either the name of the object, or the value of a VLAN tag in
the object. The list updates as you type to display matching objects.

Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Rule.
Tip You can also drag and drop selected objects.

Step 5 Add any VLAN tags that you want to specify manually. Click the Enter a VLAN Tag prompt below the
Selected VLAN Tags list; then type a VLAN tag or range and click Add. You can specify any VLAN tag
from 1 to 4094; use a hyphen to specify a range of VLAN tags.
Step 6 Save or continue editing the rule.

Firepower Management Center Configuration Guide, Version 6.3

1504
 Encrypted Traffic Handling
Port TLS/SSL Rule Conditions

Example
The following graphic shows a VLAN tag condition for an SSL rule that matches encrypted traffic
on public-facing VLANs (represented by a VLAN tag object group), as well as the manually added
VLAN 42.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
VLAN Tag Objects, on page 375

Port TLS/SSL Rule Conditions

When you build a port-based TLS/SSL rule condition, you can manually specify TCP ports. Alternately, you
can configure port conditions with port objects, which are reusable and associate a name with one or more
ports.
You can add a maximum of 50 items to each of the Selected Source Ports and Selected Destination Ports
lists in a single network condition:
• To match encrypted traffic from a TCP port, configure the Selected Source Ports.
• To match encrypted traffic to a TCP port, configure the Selected Destination Ports.
• To match encrypted traffic both originating from TCP Selected Source Portsand destined for TCP
Selected Destination Ports, configure both.

You can only configure the Selected Source Ports and Selected Destination Ports lists with TCP ports. Port
objects containing non-TCP ports are greyed out in the Available Ports list.
When building a port condition, warning icons indicate invalid configurations. For example, you can use the
object manager to edit in-use port objects so that the rules that use those object groups become invalid. For
details, hover your pointer over the icon.

Firepower Management Center Configuration Guide, Version 6.3

1505
 Encrypted Traffic Handling
Controlling Encrypted Traffic by Port

Controlling Encrypted Traffic by Port

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL rule editor, select the Ports tab.

Step 2 Find the TCP ports you want to add from the Available Ports, as follows:

• To add a TCP port object on the fly, which you can then add to the condition, click the add icon ( )
above the Available Ports list.
• To search for TCP-based port objects and groups to add, click the Search by name or value prompt
above the Available Ports list, then type either the name of the object, or the value of a port in the object.
The list updates as you type to display matching objects. For example, if you type 443, the Firepower
Management Center displays the system-provided HTTPS port object.

Step 3 To select a TCP-based port object, click it. To select all TCP-based port objects, right-click and then select
Select All. If the object includes non-TCP-based ports, you cannot add it to your port condition.
Step 4 Click Add to Source or Add to Destination.
Tip You can also drag and drop selected objects.

Step 5 Enter a Port under the Selected Source Ports or Selected Destination Ports list to manually specify source
or destination ports. You can specify a single port with a value from 0 to 65535.
Step 6 Click Add.
Note The Firepower Management Center will not add a port to a rule condition that results in an invalid
configuration.

Step 7 Save or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Port Objects, on page 373

Firepower Management Center Configuration Guide, Version 6.3

1506
 Encrypted Traffic Handling
User-Based TLS/SSL Rule Conditions

User-Based TLS/SSL Rule Conditions

You can configure TLS/SSL rules to match traffic based on realm, group, or user. Realm, group, and user
conditions in TLS/SSL rules allow you perform user control to manage which traffic can traverse your network
by associating authoritative users with IP addresses.
For traffic to match a TLS/SSL rule with a user condition, the IP address of either the source or destination
host in the monitored session must be associated with a logged in authoritative user. You can control traffic
based on realms, individual users, or the groups those users belong to.

Controlling Encrypted Traffic Based on User

Smart License Classic License Supported Devices Supported Domains Access

Any Control Any except NGIPSv Any Admin/Access

Admin/Network
Admin

Before you begin

• Configure one or more authoritative user identity sources as described in User Identity Sources.
• Configure a realm as described in Create a Realm, on page 2092.

Procedure

Step 1 In the SSL rule editor, select the Users tab.

Step 2 Search by name or value above the Available Realms list and select a realm.
Step 3 Search by name or value above the Available Users list and select a user or group.
Step 4 Click Add to Rule.
Tip You can also drag and drop selected users and groups.

Step 5 Save or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Reputation-Based TLS/SSL Rule Conditions

Reputation-based conditions in TLS/SSL rules allow you to manage which encrypted traffic can traverse your
network, by contextualizing your network traffic and limiting it where appropriate. SSL rules govern the
following types of reputation-based control:

Firepower Management Center Configuration Guide, Version 6.3

1507
 Encrypted Traffic Handling
Selected Applications and Filters in TLS/SSL Rules

• Application conditions allow you to perform application control. When the system analyzes encrypted
IP traffic, it can identify and classify commonly used encrypted applications on your network prior to
decrypting the encrypted session. The system uses this discovery-based application awareness feature
to allow you to control encrypted application traffic on your network.
I a single TLS/SSL rule, you can select individual applications, including custom applications. You can
use system-provided application filters, which are named sets of applications organized according to its
basic characteristics: type, risk, business relevance, and categories.
• URL conditions allow you to control web traffic based on a websites’ assigned category and reputation.

Selected Applications and Filters in TLS/SSL Rules

Cisco frequently updates and adds additional detectors via system and vulnerability database (VDB) updates.
You can also create your own detectors and assign characteristics (risk, relevance, and so on) to the applications
they detect. By using filters based on application characteristics, you can ensure that the system uses the most
up-to-date detectors to monitor application traffic.
For traffic to match a TLS/SSL rule with an application condition, the traffic must match one of the filters or
applications that you add to a Selected Applications and Filters list.

Note When you filter application traffic using access control rules, you can use application tags as a criterion. to
filter. However, you cannot use application tags to filter encrypted traffic because there is no benefit. All
applications that the system can detect in encrypted traffic are tagged SSL Protocol; applications without this
tag can only be detected in unencrypted or decrypted traffic.

In a single application condition, you can add a maximum of 50 items to the Selected Applications and
Filters list. Each of the following counts as an item:
• One or more filters from the Application Filters list, individually or in custom combination. This item
represents set of applications, grouped by characteristic.
• A filter created by saving search of the applications in the Available Applications list. This item represents
a set of applications, grouped by substring match.
• An individual application from the Available Applications list.

In the web interface, filters added to a condition are listed above and separately from individually added
applications.
Note that when you deploy an SSL policy, for each rule with an application condition, the system generates
a list of unique applications to match. In other words, you may use overlapping filters and individually specified
applications to ensure complete coverage.

Application Filters in TLS/SSL Rules

When building an application condition in a TLS/SSL rule, use the Application Filters list to create a set of
applications, grouped by characteristic, whose traffic you want to match.

Firepower Management Center Configuration Guide, Version 6.3

1508
 Encrypted Traffic Handling
Available Applications in TLS/SSL Rules

For your convenience, the system characterizes each application by type, risk, business relevance, category,
and tag. You can use these criteria as filters or create custom combinations of filters to perform application
control.
Note that the mechanism for filtering applications in a TLS/SSL rule is the same as that for creating reusable,
custom application filters using the object manager. You can also save many filters you create on-the-fly in
access control rules as new, reusable filters. You cannot save a filter that includes another user-created filter
because you cannot nest user-created filters.

Understanding How Filters Are Combined

When you select filters, singly or in combination, the Available Applications list updates to display only the
applications that meet your criteria. You can select system-provided filters in combination, but not custom
filters.
The system links multiple filters of the same filter type with an OR operation. For example, if you select the
Medium and High filters under the Risks type, the resulting filter is:

Risk: Medium OR High

If the Medium filter contained 110 applications and the High filter contained 82 applications, the system
displays all 192 applications in the Available Applications list.
The system links different types of filters with an AND operation. For example, if you select the Medium and
High filters under the Risks type, and the Medium and High filters under the Business Relevance type, the
resulting filter is:

Risk: Medium OR High

AND
Business Relevance: Medium OR High

In this case, the system displays only those applications that are included in both the Medium or High Risk
type AND the Medium or High Business Relevance type.

Finding and Selecting Filters

To select filters, click the arrow next to a filter type to expand it, then select or clear the check box next to
each filter whose applications you want to display or hide. You can also right-click a Cisco-provided filter
type (Risks, Business Relevance, Types, or Categories) and select Check All or Uncheck All.
To search for filters, click the Search by name prompt above the Available Filters list, then type a name.
The list updates as you type to display matching filters.
After you are done selecting filters, use the Available Applications list to add those filters to the rule.
Related Topics
Application Filters, on page 375

Available Applications in TLS/SSL Rules

When building an application condition in a TLS/SSL rule, use the Available Applications list to select the
applications whose traffic you want to match.

Firepower Management Center Configuration Guide, Version 6.3

1509
 Encrypted Traffic Handling
Available Applications in TLS/SSL Rules

Browsing the List of Applications

When you first start to build the condition the list is unconstrained, and displays every application the system
detects, 100 at a time:
• To page through the applications, click the arrows underneath the list.
• To display a pop-up window with summary information about the application’s characteristics, as well
as Internet search links that you can follow, click the information icon ( ) next to an application.

Finding Applications to Match

To help you find the applications you want to match, you can constrain the Available Applications list in
the following ways:
• To search for applications, click the Search by name prompt above the list, then type a name. The list
updates as you type to display matching applications.
• To constrain the applications by applying a filter, use the Application Filters list. The Available
Applications list updates as you apply filters.

Once constrained, an All apps matching the filter option appears at the top of the Available Applications
list.

Note If you select one or more filters in the Application Filters list and also search the Available Applications list,
your selections and the search-filtered Available Applications list are combined using an AND operation.
That is, the All apps matching the filter condition includes all the individual conditions currently displayed
in the Available Applications list as well as the search string entered above the Available Applications list.

Selecting Single Applications to Match in a Condition

After you find an application you want to match, click to select it. To select all applications in the current
constrained view, right-click and select Select All.
In a single application condition, you can match a maximum of 50 applications by selecting them individually;
to add more than 50 you must either create multiple TLS/SSL rules or use filters to group applications.

Selecting All Applications Matching a Filter for a Condition

Once constrained by either searching or using the filters in the Application Filters list, the All apps matching
the filter option appears at the top of the Available Applications list.
This option allows you to add the entire set of applications in the constrained Available Applications list to
the Selected Applications and Filters list, at once. In contrast to adding applications individually, adding
this set of applications counts as only one item against the maximum of 50, regardless of the number of
individual application that comprise it.
When you build an application condition this way, the name of the filter you add to the Selected Applications
and Filters list is a concatenation of the filter types represented in the filter plus the names of up to three
filters for each type. More than three filters of the same type are followed by an ellipsis (...). For example, the
following filter name includes two filters under the Risks type and four under Business Relevance:

Firepower Management Center Configuration Guide, Version 6.3

1510
 Encrypted Traffic Handling
Application-Based TLS/SSL Rule Condition Requirements

Risks: Medium, High Business Relevance: Low, Medium, High,...

Filter types that are not represented in a filter you add with All apps matching the filter are not included in
the name of the filter you add. The instructional text that is displayed when you hover your pointer over the
filter name in the Selected Applications and Filters list indicates that these filter types are set to any; that
is, these filter types do not constrain the filter, so any value is allowed for these.
You can add multiple instances of All apps matching the filter to an application condition, with each instance
counting as a separate item in the Selected Applications and Filters list. For example, you could add all high
risk applications as one item, clear your selections, then add all low business relevance applications as another
item. This application condition matches applications that are high risk OR have low business relevance.

Application-Based TLS/SSL Rule Condition Requirements

For encrypted traffic to match a TLS/SSL rule with an application condition, the traffic must match one of
the filters or applications that you add to a Selected Applications and Filters list.
You can add a maximum of 50 items per condition, and filters added to a condition are listed above and
separately from individually added applications. When building an application condition, warning icons
indicate invalid configurations. For details, hover your pointer over the icon.

Adding an Application Condition to a TLS/SSL Rule

Smart License Classic License Supported Devices Supported Domains Access

Any Control Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL rule editor, select the Applications tab.

Step 2 If you want to constrain the list of applications displayed in the Available Applications list, you must select
one or more filters in the Application Filters list. For more information, see Application Filters in TLS/SSL
Rules, on page 1508.
Step 3 Find and select the applications you want to add from the Available Applications list. You can search for
and select individual applications, or, when the list is constrained, All apps matching the filter. For more
information, see Available Applications in TLS/SSL Rules, on page 1509.
Step 4 Click Add to Rule.
Tip Click Clear All Filters to clear your existing selections. You can also drag and drop selected
applications and filters.

Step 5 Save or continue editing the rule.

Firepower Management Center Configuration Guide, Version 6.3

1511
 Encrypted Traffic Handling
Limitations to Encrypted Application Control

Example
The following graphic shows the application condition for a TLS/SSL rule that decrypts a custom
group of applications for MyCompany, all applications with high risk and low business relevance,
gaming applications, and some individually selected applications.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Limitations to Encrypted Application Control

Encrypted Application Identification
The system can identify unencrypted applications that become encrypted using StartTLS. This includes such
applications as 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 server certificate
subject distinguished name value.

Speed of Application Identification

The system cannot perform application control on encrypted traffic before:
• An encrypted connection is established between a client and server, and
• The system identifies the application in the encrypted session

This identification occurs after the server certificate exchange. If traffic exchanged during the TLS/SSL
handshake matches all other conditions in a TLS/SSL rule containing an application condition but the
identification is not complete, the SSL policy allows the packet to pass. This behavior allows the handshake
to complete so that applications can be identified. For your convenience, affected rules are marked with an
information icon ( ).
After the system completes its identification, the system applies the TLS/SSL rule action to the remaining
session traffic that matches its application condition.

Firepower Management Center Configuration Guide, Version 6.3

1512
 Encrypted Traffic Handling
Reputation-Based URL Blocking in Encrypted Traffic

Automatically Enabling Application Detectors

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.
Related Topics
Activating and Deactivating Detectors, on page 2083

Reputation-Based URL Blocking in Encrypted Traffic

With a URL Filtering license, URL conditions in TLS/SSL rules can control access to encrypted websites,
based on the category and reputation of the requested URLs. For detailed information, see URL Conditions
(URL Filtering), on page 342.

Tip URL conditions in TLS/SSL rules do not support manual URL filtering. Instead, use a distinguished name
condition matching on the subject common name.

Block Encrypted Traffic Based on URL Reputation

Smart License Classic License Supported Devices Supported Domains Access

URL Filtering URL Filtering Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL rule editor, select the Category tab.

Step 2 Find the categories of URL you want to add from the Categories list. To match encrypted web traffic regardless
of category, select Any category. To search for categories to add, click the Search by name or value prompt
above the Categories list, then type the category name. The list updates as you type to display matching
categories.
Step 3 To select a category, click it.
Tip Although you can right-click and Select All categories, adding all categories this way exceeds the
50-item maximum for a TLS/SSL rule. Instead, use Any.

Step 4 If you want to qualify your category selections, you must click a reputation level from the Reputations list.
You can only select one reputation level. If you do not specify a reputation level, the system defaults to Any,
meaning all levels.
• If the rule blocks web access or decrypts traffic (the rule action is Block, Block with reset, Decrypt -
Known Key, Decrypt - Resign, or Monitor) selecting a reputation level also selects all reputations more
severe than that level. For example, if you configure a rule to block Suspicious sites (level 2), it also
automatically blocks High Risk (level 1) sites.

Firepower Management Center Configuration Guide, Version 6.3

1513
 Encrypted Traffic Handling
Server Certificate-Based TLS/SSL Rule Conditions

• If the rule allows web access, subject to access control (the rule action is Do not decrypt), selecting a
reputation level also selects all reputations less severe than that level. For example, if you configure a
rule to allow Benign sites (level 4), it also automatically allows Well known (level 5) sites.
Note If you change the rule action for a rule, the system automatically changes the reputation levels
in URL conditions according to the above points.

Step 5 Click Add to Rule to add the selected items to the Selected Categories list.
Tip You can also drag and drop selected items.

Step 6 Save or continue editing the rule.

Example
The following graphic shows the URL condition for an example access control rule that blocks: all
malware sites, all high-risk sites, and all non-benign social networking sites.

The following table summarizes how you build the condition shown in the graphic above.

Table 101: Example: Building A URL Condition

To block... Select this Category or URL And this Reputation...

Object...

malware sites, regardless of Malware Sites Any

reputation

any URL with a high risk (level 1) Any 1 - High Risk

social networking sites with a risk Social Network 3 - Benign sites with security risks
greater than benign (levels 1
through 3)

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Server Certificate-Based TLS/SSL Rule Conditions

TLS/SSL rules can handle and decrypt encrypted traffic based on server certificate characteristics. You can
configure TLS/SSL rules based on the following server certificate attributes:

Firepower Management Center Configuration Guide, Version 6.3

1514
 Encrypted Traffic Handling
Certificate Distinguished Name TLS/SSL Rule Conditions

• Distinguished name conditions allow you to handle and inspect encrypted traffic based on the CA that
issued a server certificate, or the certificate holder. Based on the issuer distinguished name, you can
handle traffic based on the CA that issued a site’s server certificate.
• Certificate conditions in TLS/SSL rules allow you to handle and inspect encrypted traffic based on the
server certificate used to encrypt that traffic. You can configure a condition with one or more certificates;
traffic matches the rule if the certificate matches any of the condition’s certificates.
• Certificate status conditions in TLS/SSL rules allow you to handle and inspect encrypted traffic based
on the status of the server certificate used to encrypt the traffic, including whether a certificate is valid,
revoked, expired, not yet valid, self-signed, signed by a trusted CA, whether the Certificate Revocation
List (CRL) is valid; whether the Server Name Indication (SNI) in the certificate matches the server in
the request.
• Cipher suite conditions in TLS/SSL rules allow you to handle and inspect encrypted traffic based on the
cipher suite used to negotiate the encrypted session.
• Session conditions in TLS/SSL rules allow you to inspect encrypted traffic based on the SSL or TLS
version used to encrypt the traffic.

To detect multiple cipher suites in a rule, the certificate issuer, or the certificate holder, you can create reusable
cipher suite list and distinguished name objects and add them to your rule. To detect the server certificate and
certain certificate statuses, you must create external certificate and external CA objects for the rule.

Certificate Distinguished Name TLS/SSL Rule Conditions

When configuring the rule condition, you can manually specify a literal value, reference a distinguished name
object, or reference a distinguished name group containing multiple objects.

Note You cannot configure a distinguished name condition if you also choose the Decrypt - Known Key action.
Because that action requires you to choose a server certificate to decrypt traffic, the certificate already matches
the traffic.

You can match against multiple subject and issuer distinguished names in a single certificate status rule
condition; only one common or distinguished name needs to match to match the rule.
If you add a distinguished name manually, it can contain the common name attribute (CN). If you add a
common name without CN=, the system prepends CN= before saving the object.
You can also add a distinguished name with one each of the following attributes, separated by commas: C,
CN, O, OU.
In a single DN condition, you can add a maximum of 50 literal values and distinguished name objects to the
Subject DNs, and 50 literal values and distinguished name objects to the Issuer DNs.
The system-provided DN object group, Cisco-Undecryptable-Sites, contains websites whose traffic the system
cannot decrypt. You can add this group to a DN condition to block or not decrypt traffic to or from these
websites, without wasting system resources attempting to decrypt that traffic. You can modify individual
entries in the group. You cannot delete the group. System updates can modify the entries on this list, but the
system preserves user changes.
The first time the system detects an encrypted session to a new server, DN data is not available for ClientHello
processing, which can result in an undecrypted first session. After the initial session, the managed device

Firepower Management Center Configuration Guide, Version 6.3

1515
 Encrypted Traffic Handling
Controlling Encrypted Traffic by Certificate Distinguished Name

caches data from the server Certificate message. For subsequent connections from the same client, the system
can match the ClientHello message conclusively to rules with DN conditions and process the message to
maximize decryption potential.

Controlling Encrypted Traffic by Certificate Distinguished Name

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL rule editor, select the DN tab.

Step 2 Find the distinguished names you want to add from the Available DNs, as follows:
• To add a distinguished name object on the fly, which you can then add to the condition, click the add
icon ( ) above the Available DNs list.
• To search for distinguished name objects and groups to add, click the Search by name or value prompt
above the Available DNs list, then type either the name of the object, or a value in the object. The list
updates as you type to display matching objects.

Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Subject or Add to Issuer.
Tip You can also drag and drop selected objects.

Step 5 Add any literal common names or distinguished names that you want to specify manually. Click the Enter
DN or CN prompt below the Subject DNs or Issuer DNs list; then type a common name or distinguished
name and click Add.
Step 6 Add or continue editing the rule.

Example

Example
The following graphic illustrates a distinguished name rule condition searching for certificates issued
to goodbakery.example.com or issued by goodca.example.com. Traffic encrypted with these
certificates is allowed, subject to access control.

Firepower Management Center Configuration Guide, Version 6.3

1516
 Encrypted Traffic Handling
Certificate TLS/SSL Rule Conditions

The following graphic illustrates a distinguished name rule condition searching for certificates issued
to badbakery.example.com and associated domains, or certificates issued by badca.example.com.
Traffic encrypted with these certificates is decrypted using a re-signed certificate.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Distinguished Name Objects, on page 413

Certificate TLS/SSL Rule Conditions

When you build a certificate-based TLS/SSL rule condition, you can upload a server certificate; you save the
certificate as an external certificate object, which is reusable and associates a name with a server certificate.
Alternately, you can configure certificate conditions with existing external certificate objects and object
groups.
You can search the Available Certificates field in the rule condition based for external certificate objects
and object groups based on the following certificate distinguished name characteristics:
• Subject or issuer common name (CN)
• Subject or issuer organization (O)
• Subject or issuer organizational unit (OU)

You can choose to match against multiple certificates in a single certificate rule condition; if the certificate
used to encrypt the traffic matches any of the uploaded certificates, the encrypted traffic matches the rule.
You can add a maximum of 50 external certificate objects and external certificate object groups to the Selected
Certificates in a single certificate condition.
Note the following:
• You cannot configure a certificate condition if you also select the Decrypt - Known Key action. Because
that action requires you to select a server certificate to decrypt traffic, the implication is that the certificate
already matches the traffic.

Firepower Management Center Configuration Guide, Version 6.3

1517
 Encrypted Traffic Handling
Controlling Encrypted Traffic by Certificate

• If you configure a certificate condition with an external certificate object, any cipher suites you add to
a cipher suite condition, or internal CA objects you associate with the Decrypt - Resign action, must
match the external certificate’s signature algorithm type. For example, if your rule’s certificate condition
references an EC-based server certificate, any cipher suites you add, or CA certificates you associate
with the Decrypt - Resign action, must also be EC-based. If you mismatch signature algorithm types in
this case, the policy editor displays a warning icon next to the rule.
• The first time the system detects an encrypted session to a new server, certificate data is not available
for ClientHello processing, which can result in an undecrypted first session. After the initial session, the
managed device caches data from the server Certificate message. For subsequent connections from the
same client, the system can match the ClientHello message conclusively to rules with certificate conditions
and process the message to maximize decryption potential.

Controlling Encrypted Traffic by Certificate

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL rule editor, select the Certificate tab.

Step 2 Find the server certificates you want to add from the Available Certificates, as follows;
• To add an external certificate object on the fly, which you can then add to the condition, click the add
icon ( ) above the Available Certificates list.
• To search for certificate objects and groups to add, click the Search by name or value prompt above
the Available Certificates list, then type either the name of the object, or a value in the object. The list
updates as you type to display matching objects.

Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Rule.
Tip You can also drag and drop selected objects.

Step 5 Add or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
External Certificate Objects, on page 424

Firepower Management Center Configuration Guide, Version 6.3

1518
 Encrypted Traffic Handling
Certificate Status TLS/SSL Rule Conditions

Certificate Status TLS/SSL Rule Conditions

For each certificate status TLS/SSL rule condition you configure, you can match traffic against the presence
or absence of a given status. You can select several statuses in one rule condition; if the certificate matches
any of the selected statuses, the rule matches the traffic.
You can choose to match against the presence or absence of multiple certificate statuses in a single certificate
status rule condition; the certificate needs to match only one of the criteria to match the rule.
You should consider, when setting this parameter, whether you're configuring a decrypt rule or a block rule.
Typically, you should click Yes for a block rule and No for a decrypt rule. Examples:
• If you're configuring a Decrypt - Resign rule, the default behavior is to decrypt traffic with an expired
certificate. To change that behavior, click No for Expired so traffic with an expired certificate is not
decrypted and resigned.
• If you're configuring a Block rule, the default behavior is to allow traffic with an expired certificate. To
change that behavior click Yes for Expired so traffic with an expired certificate is blocked.

The following table describes how the system evaluates encrypted traffic based on the encrypting server
certificate’s status.

Table 102: Certificate Status Rule Condition Criteria

Status Check Status Set to Yes Status Set to No

Revoked The policy trusts the CA that issued The policy trusts the CA that issued
the server certificate, and the CA the server certificate, and the CA
certificate uploaded to the policy certificate uploaded to the policy
contains a CRL that revokes the does not contain a CRL that
server certificate. revokes the certificate.

Self-signed The detected server certificate The detected server certificate

contains the same subject and issuer contains different subject and issuer
distinguished name. distinguished names.

Valid All of the following are true: At least one of the following is true:
• The policy trusts the CA that • The policy does not trust the
issued the certificate. CA that issued the certificate.
• The signature is valid. • The signature is invalid.
• The issuer is valid. • The issuer is invalid.
• None of the policy’s trusted • A trusted CA in the policy
CAs revoked the certificate. revoked the certificate.
• The current date is between • The current date is before the
the certificate Valid From and certificate Valid From date.
Valid To date.
• The current date is after the
certificate Valid To date.

Firepower Management Center Configuration Guide, Version 6.3

1519
 Encrypted Traffic Handling
Certificate Status TLS/SSL Rule Conditions

Status Check Status Set to Yes Status Set to No

Invalid signature The certificate’s signature cannot The certificate’s signature is

be properly validated against the properly validated against the
certificate’s content. certificate’s content.

Invalid issuer The issuer CA certificate is not The issuer CA certificate is stored
stored in the policy’s list of trusted in the policy’s list of trusted CA
CA certificates. certificates.

Expired The current date is after the The current date is before or on the
certificate Valid To date. certificate Valid To date.

Not yet valid The current date is before the The current date is after or on the
certificate Valid From date. certificate Valid From date.

Firepower Management Center Configuration Guide, Version 6.3

1520
Encrypted Traffic Handling
Certificate Status TLS/SSL Rule Conditions

Status Check Status Set to Yes Status Set to No

Invalid certificate The certificate is not valid. At least The certificate is valid. All of the
one of the following is true: following are true:
• Invalid or inconsistent • Valid certificate extension.
certificate extension; that is, a
certificate extension had an • The certificate can be used for
invalid value (for example, an the specified purpose.
incorrect encoding) or some • Valid Basic Constraints path
value inconsistent with other length.
extensions.
• Valid values for Not Before
• The certificate cannot be used and Not After.
for the specified purpose.
• Valid name constraint.
• The Basic Constraints path
length parameter has been • The root certificate is trusted
exceeded. for the specified purpose.
For more information, see • The root certificate accepts the
RFC 5280, section 4.2.1.9. specified purpose.
• The certificate's value for Not
Before or Not After is invalid.
These dates can be encoded as
UTCTime or GeneralizedTime
For more information, see
RFC 5280 section 4.1.2.5.
• The format of the name
constraint is not recognized;
for example, an email address
format of a form not
mentioned in RFC 5280,
section 4.2.1.10. This could
be caused by an improper
extension or some new feature
not currently supported.
An unsupported name
constraint type was
encountered. OpenSSL
currently supports only
directory name, DNS name,
email, and URI types.
• The root certificate authority
is not trusted for the specified
purpose.
• The root certificate authority
rejects the specified purpose.

Firepower Management Center Configuration Guide, Version 6.3

1521
 Encrypted Traffic Handling
Trusting External Certificate Authorities

Status Check Status Set to Yes Status Set to No

Invalid CRL The Certificate Revocation List The CRL is valid. All of the
(CRL) digital signature is not valid. following are true:
At least one of the following is true:
• Next Update and Last Update
• The value of the CRL's Next fields are valid.
Update or Last Update field is
invalid. • The CRL's date is valid.

• The CRL is not yet valid. • The path is valid.

• The CRL has expired. • The CRL was found.

• An error occurred when • The CRL matches the

attempting to verify the CRL certificate's scope.
path. This error occurs only if
extended CRL checking is
enabled.
• CRL could not be found.
• The only CRLs that could be
found did not match the scope
of the certificate.

Server mismatch The server name does not match The server name matches the SNI
the server's Server Name Indication name of the server to which the
(SNI) name, which could indicate client is requesting access.
an attempt to spoof the server
name.

Note that even though a certificate might match more than one status, the rule causes an action to be taken on
the traffic only once.
Checking whether a CA issued or revoked a certificate requires uploading root and intermediate CA certificates
and associated CRLs as objects. You then add these trusted CA objects to an SSL policy’s list of trusted CA
certificates.

Trusting External Certificate Authorities

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

You can trust CAs by adding root and intermediate CA certificates to your SSL policy, then use these trusted
CAs to verify server certificates used to encrypt traffic.
If a trusted CA certificate contains an uploaded certificate revocation list (CRL), you can also verify whether
a trusted CA revoked the encryption certificate.

Firepower Management Center Configuration Guide, Version 6.3

1522
 Encrypted Traffic Handling
Trusted External Certificate Authority Configuration

Procedure

Step 1 In the SSL rule editor, select the Trusted CA Certificates tab.
Step 2 Find the trusted CAs you want to add from the Available Trusted CAs, as follows:

• To add a trusted CA object on the fly, which you can then add to the condition, click the add icon ( )
above the Available Trusted CAs list.
• To search for trusted CA objects and groups to add, click the Search by name or value prompt above
the Available Trusted CAs list, then type either the name of the object, or a value in the object. The list
updates as you type to display matching objects.

Step 3 To select an object, click it. To select all objects, right-click and then select Select All.
Step 4 Click Add to Rule.
Tip You can also drag and drop selected objects.

Step 5 Add or continue editing the rule.

What to do next
• Add a certificate status TLS/SSL rule condition to your SSL rule. See Matching Traffic on Certificate
Status, on page 1524 for more information.
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Trusted Certificate Authority Objects, on page 421

Trusted External Certificate Authority Configuration

Verified server certificates include certificates signed by trusted CAs. After you add trusted CA certificates
to the SSL policy, you can configure a TLS/SSL rule with certificate status conditions to match against this
traffic.

Tip Upload all certificates within a root CA’s chain of trust to the list of trusted CA certificates, including the root
CA certificate and all intermediate CA certificates. Otherwise, it is more difficult to detect trusted certificates
issued by intermediate CAs. Also, if you configure certificate status conditions to trust traffic based on the
root issuer CA, all traffic within a trusted CA’s chain of trust can be allowed without decryption, rather than
unnecessarily decrypting it.

When you create an SSL policy, the system populates the Trusted CA Certificates tab with a default Trusted
CA object group, Cisco Trusted Authorities.
You can modify individual entries in the group, and choose whether to include this group in your SSL policy.
You cannot delete the group. System updates can modify the entries on this list, but user changes are preserved.

Firepower Management Center Configuration Guide, Version 6.3

1523
 Encrypted Traffic Handling
Matching Traffic on Certificate Status

Matching Traffic on Certificate Status

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Before you begin

• Add a trusted CA object or group to your SSL policy. See Trusting External Certificate Authorities, on
page 1522 for more information.

Procedure

Step 1 In the Firepower Management Center, choose Policies > Access Control > SSL.
Step 2 Add a new policy or edit an existing policy.
Step 3 Add a new TLS/SSL rule or edit an existing rule.
Step 4 In the Add Rule or Editing Rule dialog box, choose the Cert Status tab.
Step 5 For each certificate status, you have the following options:
• Choose Yes to match against the presence of that certificate status.
• Choose No to match against the absence of that certificate status.
• Choose Any to skip the condition when matching the rule. In other words, choosing Any means the rule
matches whether the certificate status is present or absent.

Step 6 Add or continue editing the rule.

Example
The organization trusts the Verified Authority certificate authority. The organization does not trust
the Spammer Authority certificate authority. The system administrator uploads the Verified Authority
certificate and an intermediate CA certificate issued by Verified Authority to the system. Because
Verified Authority revoked a certificate it previously issued, the system administrator uploads the
CRL that Verified Authority provided.
The following graphic illustrates a certificate status rule condition checking for valid certificates,
those issued by a Verified Authority, are not on the CRL, and still within the Valid From and Valid
To date. Because of the configuration, traffic encrypted with these certificates is not decrypted and
inspected with access control.

Firepower Management Center Configuration Guide, Version 6.3

1524
 Encrypted Traffic Handling
Cipher Suite TLS/SSL Rule Conditions

The following graphic illustrates a certificate status rule condition checking for the absence of a
status. In this case, because of the configuration, it matches against traffic encrypted with a certificate
that has not expired and monitors that traffic.

The following graphic illustrates a certificate status rule condition that matches on the presence or
absence of several statuses. Because of the configuration, if the rule matches incoming traffic encrypted
with a certificate issued by an invalid user, self-signed, invalid, or expired, it decrypts the traffic with
a known key.

The following graphic illustrates a certificate status rule condition that matches if the SNI of the
request matches the server name or if the CRL is not valid. Because of the configuration, if the rule
matches either condition, traffic is blocked.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Cipher Suite TLS/SSL Rule Conditions

The system provides predefined cipher suites you can add to a cipher suite rule condition. You can also add
cipher suite list objects containing multiple cipher suites.

Note You cannot add new cipher suites. You can neither modify nor delete predefined cipher suites.

You can add a maximum of 50 cipher suites and cipher suite lists to the Selected Cipher Suites in a single
cipher suite condition. The system supports adding the following cipher suites to a cipher suite condition:
• SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
• SSL_RSA_FIPS_WITH_DES_CBC_SHA
• TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Firepower Management Center Configuration Guide, Version 6.3

1525
 Encrypted Traffic Handling
Cipher Suite TLS/SSL Rule Conditions

• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
• TLS_DHE_RSA_WITH_DES_CBC_SHA
• TLS_DH_Anon_WITH_AES_128_GCM_SHA256
• TLS_DH_Anon_WITH_AES_256_GCM_SHA384
• TLS_DH_Anon_WITH_CAMELLIA_128_CBC_SHA
• TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
• TLS_DH_Anon_WITH_CAMELLIA_256_CBC_SHA
• TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_NULL_SHA
• TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Firepower Management Center Configuration Guide, Version 6.3

1526
Encrypted Traffic Handling
Cipher Suite TLS/SSL Rule Conditions

• TLS_ECDHE_RSA_WITH_NULL_SHA
• TLS_ECDHE_RSA_WITH_RC4_128_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_WITH_NULL_MD5
• TLS_RSA_WITH_NULL_SHA
• TLS_RSA_WITH_RC4_128_MD5
• TLS_RSA_WITH_RC4_128_SHA

Note the following:

• If you add cipher suites not supported for your deployment, you cannot deploy your configuration. For
example, passive deployments do not support decrypting traffic with the any of the ephemeral
Diffie-Hellman (DHE) or ephemeral elliptic curve Diffie-Hellman (ECDHE) cipher suites. Creating a
rule with these cipher suites prevents you from deploying your access control policy.
• If you configure a cipher suite condition with a cipher suite, any external certificate objects you add to
a certificate condition, or internal CA objects you associate with the Decrypt - Resign action, must match
the cipher suite’s signature algorithm type. For example, if your rule’s cipher suite condition references
an EC-based cipher suite, any server certificates you add, or CA certificates you associate with the
Decrypt - Resign action, must also be EC-based. If you mismatch signature algorithm types in this case,
the policy editor displays a warning icon next to the rule.
• You can add an anonymous cipher suite to the Cipher Suite condition in an SSL rule, but keep in mind:
• The system automatically strips anonymous cipher suites during ClientHello processing. For the
system to use the rule, you must also configure your TLS/SSL rules in an order that prevents
ClientHello processing. For more information, see SSL Rule Order, on page 355.
• You cannot use either the Decrypt - Resign or Decrypt - Known Key action in the rule, because
the system cannot decrypt traffic encrypted with an anonymous cipher suite.

Firepower Management Center Configuration Guide, Version 6.3

1527
 Encrypted Traffic Handling
Controlling Encrypted Traffic by Cipher Suite

• When specifying a cipher suite as a rule condition, consider that the rule matches on the negotiated cipher
suite in the ServerHello message, rather than on the full list of cipher suites specified in the ClientHello
message. During ClientHello processing, the managed device strips unsupported cipher suites from the
ClientHello message. However, if this results in all specified cipher suites being stripped, the system
retains the original list. If the system retains unsupported cipher suites, subsequent evaluation results in
an undecrypted session.

Controlling Encrypted Traffic by Cipher Suite

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL rule editor, select the Cipher Suite tab.
Step 2 Find the cipher suites you want to add from the Available Cipher Suites, as follows;

• To add a cipher suite list on the fly, which you can then add to the condition, click the add icon ( )
above the Available Cipher Suites list.
• To search for cipher suites and lists to add, click the Search by name or value prompt above the Available
Cipher Suites list, then type either the name of the cipher suite, or a value in the cipher suite. The list
updates as you type to display matching cipher suites.

Step 3 To select a cipher suite, click it. To select all cipher suites, right-click and then select Select All.
Step 4 Click Add to Rule.
Tip You can also drag and drop selected cipher suites.

Step 5 Add or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Related Topics
Cipher Suite Lists, on page 412

Encryption Protocol Version TLS/SSL Rule Conditions

You can choose to match against traffic encrypted with SSL version 3.0, or TLS version 1.0, 1.1, or 1.2. By
default, all protocol versions are selected when you create a rule; if you select multiple versions, encrypted
traffic that matches any of the selected versions matches the rule. You must select at least one protocol version
when saving the rule condition.

Firepower Management Center Configuration Guide, Version 6.3

1528
 Encrypted Traffic Handling
Controlling Traffic by Encryption Protocol Version

You cannot select SSL v2.0 in a version rule condition; the system does not support decrypting traffic encrypted
with SSL version 2.0. You can configure an undecryptable action to allow or block this traffic without further
inspection.

Controlling Traffic by Encryption Protocol Version

Smart License Classic License Supported Devices Supported Domains Access

Any Any Any except Any Admin/Access

NGIPSv Admin/Network Admin

Procedure

Step 1 In the SSL rule editor, select the Version tab.

Step 2 Select the protocol versions you want to match against.
Step 3 Add or continue editing the rule.

What to do next
• Deploy configuration changes; see Deploy Configuration Changes, on page 308.

Firepower Management Center Configuration Guide, Version 6.3

1529
 Encrypted Traffic Handling
Controlling Traffic by Encryption Protocol Version

Firepower Management Center Configuration Guide, Version 6.3

1530
 CHAPTER 76
Monitor SSL Hardware Acceleration
Use the show counters command in the CLI to evaluate SSL hardware acceleration behavior. This command
lists a variety of metrics that inform you about normal activity, alerts, and potential fatal issues.

Note Use the show counters description command to see explanations for each counter. To view only counters
related to SSL hardware acceleration, use show counters description | include TLS_TRK.

• Informational Counters, on page 1531

• Alert Counters, on page 1532
• Error Counters, on page 1532
• Fatal Counters, on page 1533

Informational Counters
If a system under load is working well, you should see large counts for the following counters. Because there
are 2 sides to the tracker process per connection, you can see these counters increase by 2 per connection. The
PRIV_KEY_RECV and SECU_PARAM_RECV counters are the most important, and are highlighted. The
CONTEXT_CREATED and CONTEXT_DESTROYED counters relate to the allocation of cryptographic
chip memory.

> show counters

Protocol Counter Value Context
SSLENC CONTEXT_CREATED 258225 Summary
SSLENC CONTEXT_DESTROYED 258225 Summary
TLS_TRK OPEN_SERVER_SESSION 258225 Summary
TLS_TRK OPEN_CLIENT_SESSION 258225 Summary
TLS_TRK UPSTREAM_CLOSE 516450 Summary
TLS_TRK DOWNSTREAM_CLOSE 516450 Summary
TLS_TRK FREE_SESSION 516450 Summary
TLS_TRK CACHE_FREE 516450 Summary
TLS_TRK PRIV_KEY_RECV 258225 Summary
TLS_TRK NO_KEY_ENABLE 258225 Summary
TLS_TRK SECU_PARAM_RECV 516446 Summary
TLS_TRK DECRYPTED_ALERT 258222 Summary
TLS_TRK DECRYPTED_APPLICATION 33568976 Summary
TLS_TRK ALERT_RX_CNT 258222 Summary
TLS_TRK ALERT_RX_WARNING_ALERT 258222 Summary
TLS_TRK ALERT_RX_CLOSE_NOTIFY 258222 Summary

Firepower Management Center Configuration Guide, Version 6.3

1531
 Encrypted Traffic Handling
Alert Counters

TCP_PRX OPEN_SESSION 516450 Summary

TCP_PRX FREE_SESSION 516450 Summary
TCP_PRX UPSTREAM_CLOSE 516450 Summary
TCP_PRX DOWNSTREAM_CLOSE 516450 Summary
TCP_PRX FREE_CONN 258222 Summary
TCP_PRX SERVER_CLEAN_UP 258222 Summary
TCP_PRX CLIENT_CLEAN_UP 258222 Summary

Alert Counters
We implemented the following counters according to the TLS 1.2 specification. FATAL or BAD alerts could
indicate issues; however, ALERT_RX_CLOSE_NOTIFY is normal.
For details, see RFC 5246 section 7.2.
TLS_TRK ALERT_RX_CNT 311 Summary
TLS_TRK ALERT_TX_CNT 2 Summary
TLS_TRK ALERT_TX_IN_HANDSHAKE_CNT 2 Summary
TLS_TRK ALERT_RX_IN_HANDSHAKE_CNT 2 Summary
TLS_TRK ALERT_RX_WARNING_ALERT 308 Summary
TLS_TRK ALERT_RX_FATAL_ALERT 3 Summary
TLS_TRK ALERT_TX_FATAL_ALERT 2 Summary
TLS_TRK ALERT_RX_CLOSE_NOTIFY 308 Summary
TLS_TRK ALERT_RX_BAD_RECORD_MAC 2 Summary
TLS_TRK ALERT_TX_BAD_RECORD_MAC 2 Summary
TLS_TRK ALERT_RX_BAD_CERTIFICATE 1 Summary

Error Counters
These counters indicate system errors. These counts should be low on a healthy system. The BY_PASS
counters indicate packets that have been passed directly to or from the inspection engine (Snort) process
(which runs in software) without decryption. The following example lists some of the bad counters.
Counters with a value of 0 are not displayed. To view a complete list of counters, use the command show
counters description | include TLS_TRK

> show counters

Protocol Counter Value Context
TCP_PRX BYPASS_NOT_ENOUGH_MEM 2134 Summary
TLS_TRK CLOSED_WITH_INBOUND_PACKET 2 Summary
TLS_TRK ENC_FAIL 82 Summary
TLS_TRK DEC_FAIL 211 Summary
TLS_TRK DEC_CKE_FAIL 43194 Summary
TLS_TRK ENC_CB_FAIL 4335 Summary
TLS_TRK DEC_CB_FAIL 909 Summary
TLS_TRK DEC_CKE_CB_FAIL 818 Summary
TLS_TRK RECORD_PARSE_ERR 123 Summary
TLS_TRK IN_ERROR 44948 Summary
TLS_TRK ERROR_UPSTREAM_RECORD 43194 Summary
TLS_TRK INVALID_CONTENT_TYPE 123 Summary
TLS_TRK DOWNSTREAM_REC_CHK_ERROR 123 Summary
TLS_TRK DECRYPT_FAIL 43194 Summary
TLS_TRK UPSTREAM_BY_PASS 127 Summary
TLS_TRK DOWNSTREAM_BY_PASS 127 Summary

Firepower Management Center Configuration Guide, Version 6.3

1532
 Encrypted Traffic Handling
Fatal Counters

Fatal Counters
The fatal counters indicate serious errors. These counters should be at or near 0 on a healthy system. The
following example lists the fatal counters.

> show counters

Protocol Counter Value Context
CRYPTO RING_FULL 1 Summary
CRYPTO ACCELERATOR_CORE_TIMEOUT 1 Summary
CRYPTO ACCELERATOR_RESET 1 Summary
CRYPTO RSA_PRIVATE_DECRYPT_FAILED 1 Summary

The RING_FULL counter is not a fatal counter, but indicates how often the system overloaded the cryptographic
chip. The ACCELERATOR_RESET counter is the number of times the SSL hardware acceleration process
failed unexpectedly, which also causes the failure of pending operations, which are the numbers you see in
ACCELERATOR_CORE_TIMEOUT and RSA_PRIVATE_DECRYPT_FAILED.
If you have persistent problems, disable SSL hardware acceleration (system support ssl-hw-offload disable)
and work with Cisco Technical Support to resolve the issues.

Note You can do additional troubleshooting using the show snort tls-offload and debug snort tls-offload commands.
Use the clear snort tls-offload command to reset the counters displayed in the show snort tls-offload command
to zero.

Firepower Management Center Configuration Guide, Version 6.3

1533
 Encrypted Traffic Handling
Fatal Counters

Firepower Management Center Configuration Guide, Version 6.3

1534
 CHAPTER 77
Troubleshoot TLS/SSL Rules
You can diagnose a variety of error conditions using connection events; for example, your managed device
might be overloaded with TLS/SSL traffic, or applications might be using TLS/SSL pinning or TLS heartbeat.
These conditions might require you to adjust your SSL rules or take other actions to restore normal operation
in your network.
• About TLS/SSL Oversubscription, on page 1535
• About TLS Heartbeat, on page 1538
• About TLS/SSL Pinning, on page 1539
• Verify TLS/SSL Cipher Suites, on page 1542

About TLS/SSL Oversubscription

TLS/SSL oversubscription is a state where a managed device is overloaded with TLS/SSL traffic. Any managed
device can experience TLS/SSL oversubscription but only managed devices that support TLS/SSL hardware
acceleration provide a configurable way to handle it.
When a managed device with TLS/SSL hardware acceleration enabled is oversubscribed, any packet received
by the managed device is acted on according to the setting for Handshake Errors in the SSL policy's
Undecryptable Actions:
• Inherit default action
• Do not decrypt
• Block
• Block with reset

If the setting for Handshake Errors in the SSL policy's Undecryptable Actions is Do Not decrypt and the
associated access control policy is configured to inspect the traffic, inspection occurs; decryption does not
occur.
Related Topics
Troubleshoot TLS/SSL Oversubscription, on page 1536

Firepower Management Center Configuration Guide, Version 6.3

1535
 Encrypted Traffic Handling
Troubleshoot TLS/SSL Oversubscription

Troubleshoot TLS/SSL Oversubscription

If your managed device has TLS/SSL hardware acceleration enabled, you can view connection events to
determine whether or not the devices are experiencing SSL oversubscription. You must add at least the SSL
Flow Flags event to the table view of connection events.

Before you begin

• Enable SSL hardware acceleration on your managed devices.
• Configure an SSL policy with a setting for Handshake Errors on the Undecryptable Actions tab page.
For more information, see Set Default Handling for Undecryptable Traffic, on page 1480.
• Enable logging for your SSL rules as discussed in Logging Decryptable Connections with SSL Rules,
on page 2455.

Procedure

Step 1 If you haven't done so already, log in to the Firepower Management Center.
Step 2 Click Analysis > Connection > Events.
Step 3 Click Table View of Connection Events.
Step 4 In the table view of connection events, click x on any column to add at least the SSL Flow Flags column to
the table.

The following example shows adding the SSL Actual Action, SSL Flow Error, SSL Flow Flags, SSL Flow
Messages, SSL Policy, and SSL Rule columns to the table of connection events.

Firepower Management Center Configuration Guide, Version 6.3

1536
Encrypted Traffic Handling
Troubleshoot TLS/SSL Oversubscription

The columns are added in the order discussed in Connection and Security Intelligence Event Fields, on page
2463.

Step 5 Click Apply.

TLS/SSL oversubscription is indicated by the values of ERROR_EVENT_TRIGGERED and
OVER_SUBSCRIBED in the SSL Flow Flags column.
The following figure shows an example.

Step 6 If TLS/SSL oversubscription is occurring, log in to the managed device and enter any of the following
commands:
Command Result

show counters If the value of TCP_PRX

BYPASS_NOT_ENOUGH_MEM is large, consider
upgrading your device to one with a larger capacity
for SSL traffic or use Do Not Decrypt rules for lower
priority encrypted traffic.

show snort tls-offload If the value of BYPASS_NOT_ENOUGH_MEM is

large, consider upgrading your device to one with a
larger capacity for SSL traffic or use Do Not Decrypt
rules for lower priority encrypted traffic.

Related Topics
Troubleshoot TLS/SSL Oversubscription, on page 1536
About TLS/SSL Oversubscription, on page 1535
Using Connection and Security Intelligence Event Tables, on page 2483
Connection and Security Intelligence Event Fields, on page 2463
Information Available in Connection Event Fields, on page 2479
Event Searches, on page 2413

Firepower Management Center Configuration Guide, Version 6.3

1537
 Encrypted Traffic Handling
About TLS Heartbeat

About TLS Heartbeat

Some applications use the TLS heartbeat extension to the Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS) protocols defined by RFC6520. TLS heartbeat provides a way to confirm
the connection is still alive—either the client or server sends a specified number of bytes of data and requests
the other party echo the response. If this is successful, encrypted data is sent.
When a managed device with TLS/SSL hardware acceleration enabled encounters a packet that uses the TLS
heartbeat extension,the managed device takes the action specified by the setting for Decryption Errors in
the SSL policy's Undecryptable Actions:
• Block
• Block with reset

Related Topics
Troubleshoot TLS Heartbeat, on page 1538

Troubleshoot TLS Heartbeat

If your managed device has TLS/SSL hardware acceleration enabled, you can view connection events to
determine whether or not the devices are seeing traffic with the TLS heartbeat extension. You must add at
least the SSL Flow Messages event to the table view of connection events.

Before you begin

SSL heartbeat is indicated by the value of HEARTBEAT in the SSL Flow Messages column in the table view
of connection events. To determine if applications in your network use SSL heartbeat, first perform the
following tasks:
• Enable SSL hardware acceleration on your managed devices.
• Configure an SSL policy with a setting for Decryption Errors on the Undecryptable Actions tab page.
For more information, see Set Default Handling for Undecryptable Traffic, on page 1480.
• Enable logging for your SSL rules as discussed in Logging Decryptable Connections with SSL Rules,
on page 2455.

Procedure

Step 1 If you haven't done so already, log in to the Firepower Management Center.
Step 2 Click Analysis > Connection > Events.
Step 3 Click Table View of Connection Events.
Step 4 In the table view of connection events, click x on any column to add at least the SSL Flow Messages column
to the table.

Firepower Management Center Configuration Guide, Version 6.3

1538
 Encrypted Traffic Handling
About TLS/SSL Pinning

The following example shows adding the SSL Actual Action, SSL Flow Error, SSL Flow Flags, SSL Flow
Messages, SSL Policy, and SSL Rule columns to the table of connection events.

The columns are added in the order discussed in Connection and Security Intelligence Event Fields, on page
2463.

Step 5 Click Apply.

TLS heartbeat is indicated by the value of HEARTBEAT in the SSL Flow Messages column.
Step 6 If applications in your network use SSL heartbeat, see TLS/SSL Rule Guidelines and Limitations, on page
1483.

Related Topics
Troubleshoot TLS Heartbeat, on page 1538
About TLS Heartbeat, on page 1538
Using Connection and Security Intelligence Event Tables, on page 2483
Connection and Security Intelligence Event Fields, on page 2463
Information Available in Connection Event Fields, on page 2479
Event Searches, on page 2413

About TLS/SSL Pinning

Some applications use a technique referred to as TLS/SSL pinning or certificate pinning, which embeds the
fingerprint of the original server certificate in the application itself. As a result, if you configured a TLS/SSL
rule with a Decrypt - Resign action, when the application receives a resigned certificate from a managed
device, validation fails and the connection is aborted.
To confirm that TLS/SSL pinning is occurring, attempt to log in to a mobile application like Facebook. If a
network connection error is displayed, log in using a web browser. (For example, you cannot log in to a
Facebook mobile application but can log in to Facebook using Safari or Chrome.) You can use Firepower
Management Center connection events as further proof of TLS/SSL pinning

Firepower Management Center Configuration Guide, Version 6.3

1539
 Encrypted Traffic Handling
Troubleshoot TLS/SSL Pinning

Note TLS/SSL pinning is not limited to mobile applications.

If applications in your network use SSL pinning, see TLS/SSL Rule Guidelines and Limitations, on page 1483
Related Topics
Troubleshoot TLS/SSL Pinning, on page 1540

Troubleshoot TLS/SSL Pinning

You can view connection events to determine whether or not the devices are experiencing SSL pinning. You
must add at least the SSL Flow Flags and SSL Flow Messages columns to the table view of connection
events.

Before you begin

• Enable SSL hardware acceleration on your managed devices.
• Enable logging for your TLS/SSL rules as discussed in Logging Decryptable Connections with SSL
Rules, on page 2455.
• Log in to a mobile application like Facebook; if a network connection error displays, log in to Facebook
using Chrome or Safari. If you can log in using a web browser but not the native application, SSL pinning
is likely occurring.

Procedure

Step 1 If you haven't done so already, log in to the Firepower Management Center.
Step 2 Click Analysis > Connection > Events.
Step 3 Click Table View of Connection Events.
Step 4 Click x on any column to add additional columns to at least the SSL Flow Flags and SSL Flow Messages
columns the connection events table.

The following example shows adding the SSL Actual Action, SSL Flow Error, SSL Flow Flags, SSL Flow
Messages, SSL Policy, and SSL Rule columns to the table of connection events.

Firepower Management Center Configuration Guide, Version 6.3

1540
Encrypted Traffic Handling
Troubleshoot TLS/SSL Pinning

The columns are added in the order discussed in Connection and Security Intelligence Event Fields, on page
2463.

Step 5 Click Apply.

Step 6 The following paragraphs discuss how you can identify SSL pinning behavior.
Step 7 If you determine that applications in your network use SSL pinning, see TLS/SSL Rule Guidelines and
Limitations, on page 1483.

What to do next
You can use TLS/SSL connection events to confirm TLS/SSL pinning is occurring by looking for any of the
following:
• Applications that send an SSL ALERT Message as soon as the client receives the SERVER_HELLO,
SERVER_CERTIFICATE, SERVER_HELLO_DONE message from the server, followed by a TCP
Reset, exhibit the following symptoms. (The alert, Unknown CA (48), can be viewed using a packet
capture.)
• The SSL Flow Flags column displays ALERT_SEEN but not APP_DATA_C2S or APP_DATA_S2C.
• If your managed device has SSL hardware acceleration enabled, the SSL Flow Messages column
typically displays: CLIENT_ALERT, CLIENT_HELLO, SERVER_HELLO,
SERVER_CERTIFICATE, SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE.
• If your managed device doesn't support SSL hardware acceleration or if the feature is disabled, the
SSL Flow Messages column typically displays: CLIENT_HELLO, SERVER_HELLO,
SERVER_CERTIFICATE, SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE.
• Success is displayed in the SSL Flow Error column.

• Applications that send no alerts but instead send TCP Reset after the SSL handshake is finished exhibit
the following symptoms:

Firepower Management Center Configuration Guide, Version 6.3

1541
 Encrypted Traffic Handling
Verify TLS/SSL Cipher Suites

• The SSL Flow Flags column does not display ALERT_SEEN, APP_DATA_C2S, or
APP_DATA_S2C.
• If your managed device has SSL hardware acceleration enabled, the SSL Flow Messages column
typically displays: CLIENT_HELLO, SERVER_HELLO, SERVER_CERTIFICATE,
SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE, CLIENT_KEY_EXCHANGE,
CLIENT_CHANGE_CIPHER_SPEC, CLIENT_FINISHED, SERVER_CHANGE_CIPHER_SPEC,
SERVER_FINISHED.
• If your managed device doesn't support SSL hardware acceleration or if the feature is disabled, the
SSL Flow Messages column typically displays: CLIENT_HELLO, SERVER_HELLO,
SERVER_CERTIFICATE, SERVER_KEY_EXCHANGE, SERVER_HELLO_DONE,
CLIENT_KEY_EXCHANGE, CLIENT_CHANGE_CIPHER_SPEC,
CLIENT_FINISHED,SERVER_CHANGE_CIPHER_SPEC, SERVER_FINISHED.
• Success is displayed in the SSL Flow Error column.

Related Topics
Using Connection and Security Intelligence Event Tables, on page 2483
Connection and Security Intelligence Event Fields, on page 2463
Information Available in Connection Event Fields, on page 2479
Event Searches, on page 2413

Verify TLS/SSL Cipher Suites

Before you begin
This topic discusses actions you must take if you see the following error when saving a TLS/SSL rule that
has cipher suite conditions:
Traffic cannot match this rule; none of your selected cipher suites contain a signature
algorithm that the resigning CA's signature algorithm

The error indicates that one or more of the cipher suites you chose for the TLS/SSL rule condition are
incompatible with the certificate used in the TLS/SSL rule. To resolve the issue, you must have access to the
certificate you're using.

Note The tasks in this topic assume knowledge of how TLS/SSL encryption works.

Procedure

Step 1 When you attempt to save an SSL rule with either Decrypt - Resign or Decrypt - Known Key with specified
cipher suites, the following error is displayed:
Example:
Traffic cannot match this rule; none of your selected cipher suites contain a
signature algorithm that the resigning CA's signature algorithm

Firepower Management Center Configuration Guide, Version 6.3

1542
Encrypted Traffic Handling
Verify TLS/SSL Cipher Suites

Step 2 Locate the certificate you're using to decrypt traffic and, if necessary, copy the certificate to a system that can
run openssl commands.
Step 3 Run the following command to display the signature algorithm used by the certificate:
openssl x509 -in CertificateName -text -noout
The first few lines of output are displayed similar to the following:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4105 (0x1009)
Signature Algorithm: ecdsa-with-SHA256

Step 4 The Signature algorithm tells you the following:

• The cryptographic function used (in the preceding example, ECDSA means Elliptic Curve Digital
Signature Algorithm).
• The hash function used to create a digest of the encrypted message (in the preceding example, SHA256).

Step 5 Search a resource such as OpenSSL at University of Utah for cipher suites that match those values. The cipher
suite must be in RFC format.
You can also search a variety of other sites, such as Server Side TLS at the Mozilla wiki or Appendix C of
RFC 5246. Cipher Suites in TLS/SSL (Schannel SSP) in Microsoft documentation has a detailed explanation
of cipher suites.
Step 6 If necessary, translate the OpenSSL name to an RFC name that the Firepower Management System uses.
See the RFC mapping list on the on the https://testssl.sh site.
Step 7 The previous example, ecdsa-with-SHA256, can be found in the Modern Compatibility List on the Mozilla
wiki.
a) Choose only cipher suites that have ECDSA and SHA-256 in the name. These cipher suites follow:
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256

b) Find the corresponding RFC cipher suite on RFC mapping list. These cipher suites follow:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

Step 8 Add the preceding cipher suites to your TLS/SSL rule.

Firepower Management Center Configuration Guide, Version 6.3

1543
 Encrypted Traffic Handling
Verify TLS/SSL Cipher Suites

Firepower Management Center Configuration Guide, Version 6.3

1544
PA R T XIX
Advanced Malware Protection (AMP) and File
Control
• File Policies and Advanced Malware Protection, on page 1547
• File and Malware Inspection Performance and Storage Tuning, on page 1583
 CHAPTER 78
File Policies and Advanced Malware Protection
The following topics provide an overview of file control, file policies, file rules, AMP cloud connections, and
dynamic analysis connections.
• About File Policies and Advanced Malware Protection, on page 1547
• Malware Protection Methods, on page 1547
• How to Configure Malware Protection, on page 1551
• Cloud Connections for Malware Protection, on page 1553
• File Policies and File Rules, on page 1563
• Retrospective Disposition Changes, on page 1577
• (Optional) Malware Protection with AMP for Endpoints, on page 1577
• History for the File and Malware Chapter, on page 1582

About File Policies and Advanced Malware Protection

Advanced Malware Protection (AMP) for Firepower can detect, capture, track, analyze, log, and optionally
block the transmission of malware in network traffic. In the Firepower Management Center web interface,
this feature is called AMP for Networks, formerly called AMP for Firepower. AMP identifies malware using
threat data from the Cisco cloud and managed devices deployed inline.
Advanced Malware Protection requires a Malware license.
You implement Advanced Malware Protection using file policies, which you associate with access control
rules that handle network traffic as part of your overall access control configuration.
When the system detects malware on your network, it generates file and malware events. To analyze file and
malware event data, see File/Malware Events and Network File Trajectory, on page 2537.

Malware Protection Methods

The Firepower system applies several methods of file inspection and analysis to determine whether a file
contains malware.
Depending on the options you enable in a file rule, the system inspects files using the following tools, in order:
1. Spero Analysis, on page 1548 and AMP Cloud Lookup, on page 1548
2. Local Malware Analysis, on page 1548

Firepower Management Center Configuration Guide, Version 6.3

1547
 Advanced Malware Protection (AMP) and File Control
Spero Analysis

3. Dynamic Analysis, on page 1549

For a comparison of these tools, see Comparison of Malware Protection Methods, on page 1550.
(You can also, if you choose, block all files based on their file type. For more information, see Block All Files
by Type, on page 1550.)
See also information about Cisco's AMP for Endpoints product at (Optional) Malware Protection with AMP
for Endpoints, on page 1577 and subtopics.

Spero Analysis
Spero analysis examines structural characteristics such as metadata and header information in executable files.
After generating a Spero signature based on this information, if the file is an eligible executable file, the device
submits it to the Spero heuristic engine in the AMP cloud. Based on the Spero signature, the Spero engine
determines whether the file is malware. You can also configure rules to submit files for Spero analysis without
also submitting them to the AMP cloud.
Note that you cannot manually submit files for Spero analysis.

AMP Cloud Lookup

For files that are eligible for assessment using Advanced Malware Protection, the Firepower Management
Center performs a malware cloud lookup, querying the AMP cloud for the file's disposition based on its
SHA-256 hash value.
To improve performance, the system caches dispositions returned by the cloud and uses the cached disposition
for known files rather than querying the AMP cloud. For more information about this cache, see Cached
Disposition Longevity, on page 1548.

Local Malware Analysis

Local malware analysis allows a managed device to locally inspect executables, PDFs, office documents, and
other types of files for the most common types of malware, using a detection rule set provided by the Cisco
Talos Security Intelligence and Research Group (Talos). Because local analysis does not query the AMP
cloud, and does not run the file, local malware analysis saves time and system resources.
If the system identifies malware through local malware analysis, it updates the existing file disposition from
Unknown to Malware. The system then generates a new malware event. If the system does not identify
malware, it does not update the file disposition from Unknown to Clean. After the system runs local malware
analysis, it caches file information such as SHA-256 hash value, timestamp, and disposition, so that if detected
again within a certain period of time, the system can identify malware without additional analysis. For more
information about the cache, see Cached Disposition Longevity, on page 1548.
Local malware analysis does not require establishing communications with the Cisco Threat Grid cloud.
However, you must configure communications with the cloud to submit files preclassified as malware for
dynamic analysis, and to download updates to the local malware analysis ruleset.

Cached Disposition Longevity

Dispositions returned from an AMP cloud query, associated threat scores, and dispositions assigned by local
malware analysis, have a time-to-live (TTL) value. After a disposition has been held for the duration specified

Firepower Management Center Configuration Guide, Version 6.3

1548
 Advanced Malware Protection (AMP) and File Control
Dynamic Analysis

in the TTL value without update, the system purges the cached information. Dispositions and associated threat
scores have the following TTL values:
• Clean — 4 hours
• Unknown — 1 hour
• Malware — 1 hour

If a query against the cache identifies a cached disposition that timed out, the system re-queries the local
malware analysis database and the AMP cloud for a new disposition.

Dynamic Analysis
You can configure your file policy to automatically submit files for dynamic analysis using Cisco Threat Grid
(formerly AMP Threat Grid), Cisco’s file analysis and threat intelligence platform.
Devices submit eligible files to Cisco Threat Grid (either the public cloud or to an on-premises appliance,
whichever you have specified) regardless of whether the device stores the file.
Cisco Threat Grid runs the file in a sandbox environment, analyzes the file's behavior to determine whether
the file is malicious, and returns a threat score that indicates the likelihood that a file contains malware. From
the threat score, you can view a dynamic analysis summary report with the reasons for the assigned threat
score. You can also look in Cisco Threat Grid to view detailed reports for files that your organization submitted,
as well as scrubbed reports with limited data for files that your organization did not submit.
You can optionally configure the file policy to override AMP cloud file dispositions based on the threat score.
For more information about Cisco Cisco Threat Grid, see https://www.cisco.com/c/en/us/products/security/
threat-grid/index.html
To configure your system to perform dynamic analysis, see the topics under Dynamic Analysis Connections,
on page 1559.

Which Files Are Eligible for Dynamic Analysis?

A file's eligibility for dynamic analysis depends on:
• the file type
• the file size
• the file rule's action

Additionally:
• The system submits only files that match the file rules you configure.
• The file must have a malware cloud lookup disposition of Unknown or Unavailable at the time the file
is sent for analysis.
• The system must preclassify the file as potential malware.

Firepower Management Center Configuration Guide, Version 6.3

1549
 Advanced Malware Protection (AMP) and File Control
Block All Files by Type

Block All Files by Type

If your organization wants to block not only the transmission of malware files, but all files of a specific type,
regardless of whether the files contain malware, you can do so.
File control is supported for all file types where the system can detect malware, plus many additional file
types. These file types are grouped into basic categories, such as multimedia (swf, mp3), executables (exe,
torrent), and PDFs.
Blocking all files based on their type is not technically a malware protection feature; it does not require a
Malware license and does not query the AMP cloud.

Comparison of Malware Protection Methods

The following table details the benefits and drawbacks of each type of file analysis, as well as the way each
malware protection method determines a file's disposition.

Analysis Type Benefit Limitations Malware Identification

Spero analysis Structural analysis of Less thorough than Disposition changes from
executable files, local malware analysis Unknown to Malware only on
submits Spero signature or dynamic analysis, positive identification of
to the AMP Cloud for only for executable files malware.
analysis

Local malware analysis Consumes fewer Less thorough results Disposition changes from
resources than dynamic than dynamic analysis Unknown to Malware only on
analysis, and returns positive identification of
results more quickly, malware.
especially if the
detected malware is
common

Dynamic analysis Thorough analysis of Eligible files are Threat score determines
unknown files using uploaded to the public maliciousness of a file.
Cisco Threat Grid cloud or an on-premises Disposition is based on the threat
appliance. It takes some score threshold configured in the
time to complete file policy.
analysis

Spero analysis and local Consumes fewer Less thorough than Disposition changes from
malware analysis resources than dynamic analysis, Spero Unknown to Malware only on
configuring local analysis only for positive identification of
malware analysis and executable files malware.
dynamic analysis, while
still using AMP cloud
resources to identify
malware

Firepower Management Center Configuration Guide, Version 6.3

1550
 Advanced Malware Protection (AMP) and File Control
How to Configure Malware Protection

Analysis Type Benefit Limitations Malware Identification

Spero analysis and Uses full capabilities of Results obtained less Threat score changes based on
dynamic analysis AMP cloud in quickly than if using dynamic analysis results for files
submitting files and local malware analysis preclassified as possible
Spero signatures malware. Disposition changes
based on configured threat score
threshold in the file policy, and
from Unknown to Malware if
the Spero analysis identifies
malware.

Local malware analysis Thorough results in Consumes more Threat score changes based on
and dynamic analysis using both types of file resources than either dynamic analysis results for files
analysis alone preclassified as possible
malware. Disposition changes
from Unknown to Malware if
local malware analysis identifies
malware, or based on configured
threat score threshold in the file
policy.

Spero analysis, local Most thorough results Consumes most Threat score changes based on
malware analysis and resources in running all dynamic analysis results for files
dynamic analysis three types of file preclassified as possible
analysis malware. Disposition changes
from Unknown to Malware if
Spero analysis or local malware
analysis identifies malware, or
based on configured threat score
threshold in the file policy.

(Block transmission of Does not require a Legitimate files will (No analysis is performed.)
all files of a specified Malware license also be blocked
file type)
(This option is not
technically a malware
protection option.)

Note Preclassification does not itself determine a file's disposition; it is merely one of the factors that determine
whether a file is eligible for Dynamic Analysis.

How to Configure Malware Protection

The end-to-end process for configuring your Firepower system to perform malware protection is as follows:

Firepower Management Center Configuration Guide, Version 6.3

1551
 Advanced Malware Protection (AMP) and File Control
How to Configure Malware Protection

Do This More Info

Step Purchase and install the necessary Malware See Licensing the Firepower System, on page 79.
1 licenses.

Step Understand how file policies and malware See the chapter Access Control Using Intrusion and File
2 protection fit into your access control plan. Policies, on page 1381.

Step Understand the file analysis tools that are See Malware Protection Methods, on page 1547 and
3 available for malware protection and subtopics.
determine which ones you want to use.

Step Determine whether you will use public See Cloud Connections for Malware Protection, on page
4 clouds or private (on-premises) clouds for 1553 and subtopics.
malware file analysis and dynamic analysis.

Step If you will use private (on-premises) Cisco Contact your Cisco sales representative or authorized
5 AMP clouds: Purchase, deploy, and test reseller.
those products.

Step Configure your firewall to allow See the topics under Security, Internet Access, and
6 communications with your chosen clouds. Communication Ports, on page 2679.

Step Configure connections between the FMC See:

7 and the AMP clouds (public or private).
• Configure Communications with the AMP Cloud,
on page 1555.
• If you deployed an on-premises Cisco Threat Grid
appliance, see Connect to an On-Premises Dynamic
Analysis Appliance, on page 1560. (Access to the
public Threat Grid cloud does not require
configuration.)

Step Understand file policy and file rule See File Policy and File Rule Guidelines and Limitations,
8 restrictions. on page 1563 and subtopics.

Step Create a file policy. See Creating a File Policy, on page 1567.
9

Step Create rules within your file policy. See File Rules, on page 1571 and its subtopics.
10

Step Understand guidelines for file policies in Review File and Intrusion Inspection Order, on page 1383.
11 access control policies. (These are different
from the file rule and file policy guidelines
above.)

Step Associate the file policy with an access See Access Control Rule Configuration to Perform
12 control policy. Malware Protection, on page 1384 and Configuring an
Access Control Rule to Perform Malware Protection, on
page 1385

Firepower Management Center Configuration Guide, Version 6.3

1552
 Advanced Malware Protection (AMP) and File Control
Cloud Connections for Malware Protection

Do This More Info

Step Assign the access control policy to See Setting Target Devices for an Access Control Policy,
13 managed devices. on page 1361.

Step Deploy the access control policy to See Deploy Configuration Changes, on page 308.
14 managed devices.

Step Ensure that your system always has the See Maintain Your System: Update File Types Eligible
15 most current and powerful protection. for Dynamic Analysis, on page 1562.

Step Configure alerts for malware-related events See Configuring AMP for Networks Alerting, on page
16 and health monitoring. 2292 and information in Health Monitoring, on page 239
about the following modules:
• Local Malware Analysis
• Security Intelligence
• Threat Data Updates on Devices
• Intrusion and File Event Rate
• AMP for Firepower Status
• AMP for Endpoints Status

Step If you have not yet done so, configure See Network Discovery Policies, on page 2147 and
17 network discovery policies so that file and subtopics.
malware events can be associated with
hosts on your network.

Step (Optional) Deploy and integrate Cisco's See (Optional) Malware Protection with AMP for
18 AMP for Endpoints product to further Endpoints, on page 1577 and subtopics.
enhance malware detection.

Step Understand how to use file and malware See File/Malware Events and Network File Trajectory,
19 events to research potential issues. on page 2537.

Cloud Connections for Malware Protection

Connections to public or private clouds are required in order to perform malware protection.

Public Clouds
Cisco offers the following public cloud-based servers:
• AMP cloud—The Advanced Malware Protection (AMP) cloud is a Cisco-hosted server that uses big
data analytics and continuous analysis to provide intelligence that the system uses to detect and block
malware on your network.
The AMP cloud provides dispositions for possible malware detected in network traffic by managed
devices, as well as data updates for local malware analysis and file pre-classification.

Firepower Management Center Configuration Guide, Version 6.3

1553
 Advanced Malware Protection (AMP) and File Control
AMP Cloud Connection Configurations

If your organization has deployed AMP for Endpoints and configured Firepower to import its data, the
system imports this data from the AMP cloud, including scan records, malware detections, quarantines,
and indications of compromise (IOC).
• Cisco Threat Grid cloud—Processes eligible files that you submit for dynamic analysis, and provides
threat scores and dynamic analysis reports.

Private (On-Premises) Clouds

Alternatively, depending on your organization's privacy or security needs, you can deploy private cloud
servers:
• An AMP Private Cloud acts as a compressed, on-premises AMP cloud, as well as an anonymized proxy
to connect to the public AMP cloud.
For details, see Cisco AMP Private Cloud, on page 1556.
If you integrate with AMP for Endpoints, the AMP private cloud has some limitations. See AMP for
Endpoints and AMP Private Cloud, on page 1580.
• On-premises Cisco Threat Grid appliance—If your organization's security policy does not allow the
Firepower System to send files outside of your network, you can deploy an on-premises appliance. This
appliance does not contact the public Cisco Threat Grid cloud.
For more information, see Dynamic Analysis On-Premises Appliance (Cisco Threat Grid) , on page 1560.

Configure Connections
To configure these connections, see:
• AMP Cloud Connection Configurations, on page 1554
• Dynamic Analysis Connections, on page 1559

AMP Cloud Connection Configurations

The following topics describe AMP connection configurations for different scenarios:
• Configure Communications with the AMP Cloud, on page 1555
• Connecting to an AMP Private Cloud, on page 1557
• Integrate Firepower and AMP for Endpoints, on page 1580

The following topics are also relevant:

• Cisco AMP Private Cloud, on page 1556
• Requirements and Guidelines for AMP Cloud Connections, on page 1556
• Managing Connections to the AMP Cloud (Public or Private) , on page 1558

Firepower Management Center Configuration Guide, Version 6.3

1554
 Advanced Malware Protection (AMP) and File Control
Configure Communications with the AMP Cloud

Configure Communications with the AMP Cloud

Smart License Classic License Supported Devices Supported Domains Access

Malware Malware Any Any Admin

By default, a connection to the United States (US) AMP public cloud is configured and enabled for your
Firepower system. (This connection appears in the web interface as AMP for Networks and sometimes AMP
for Firepower.) You cannot delete or disable an AMP for Networks cloud connection, but you can use this
procedure to switch between different geographical AMP clouds, or configure an AMP private cloud connection.

Note An AMP for Endpoints connection that has not registered successfully does not disable AMP for Networks.

Before you begin

See Requirements and Guidelines for AMP Cloud Connections, on page 1556.

Procedure

Step 1 Enable and configure malware detection:

a) Choose System > Integration.
b) Click the Cisco CSI tab.
c) Select options:

Table 103:

Option Description

Enable Automatic Local Malware The local malware detection engine statically analyzes and
Detection Updates preclassifies files using signatures provided by Cisco. If you
enable this option, the Firepower Management Center checks
for signature updates once every 30 minutes.

Share URI from Malware Events with The system can send information about the files detected in
Cisco network traffic to the AMP cloud. This information includes
URI information associated with detected files and their
SHA-256 hash values. Although sharing is opt-in, transmitting
this information to Cisco helps future efforts to identify and track
malware.

Use Legacy Port 32137 for AMP for By default, Firepower uses port 443/HTTPS to communicate
Networks with the AMP public or private cloud to obtain file disposition
data. This option allows the system to use port 32137.
If you updated from a previous version of the system, this option
may be enabled.
This option will be greyed out if the FMC is configured with
Proxy settings.

Firepower Management Center Configuration Guide, Version 6.3

1555
 Advanced Malware Protection (AMP) and File Control
Requirements and Guidelines for AMP Cloud Connections

d) Click Save.
Step 2 Select the AMP cloud to use for malware detection:
If you have deployed an AMP private cloud, see Connecting to an AMP Private Cloud, on page 1557 and skip
the rest of this step.
Otherwise:
a) Select AMP > AMP Management.
b) Click the pencil icon to edit the existing AMP for Networks cloud.
c) Choose the appropriate cloud based on the geographical location of your Firepower Management Center.
d) Click Save.

What to do next
If your deployment is a high-availability configuration, see Requirements and Guidelines for AMP Cloud
Connections, on page 1556.

Requirements and Guidelines for AMP Cloud Connections

Requirements for AMP Cloud Connections

To ensure your FMC can communicate with the AMP cloud, see the topics under Security, Internet Access,
and Communication Ports, on page 2679.
To use the legacy port for AMP communications, see Communication Port Requirements, on page 2681.

AMP and High Availability

Although they share file policies and related configurations, Firepower Management Centers in a high
availability pair share neither cloud connections nor captured files, file events, and malware events. To ensure
continuity of operations, and to ensure that detected files’ malware dispositions are the same on both Firepower
Management Centers, both Active and Standby Firepower Management Centers must have access to the cloud.
In high availability configurations, you must configure AMP cloud connections independently on the Active
and Standby instances of the Firepower Management Center; these configurations are not synchronized.
These requirements apply to both public and private AMP clouds.

AMP Cloud Connections and Multitenancy

In a multidomain deployment, you configure the AMP for Networks connection at the Global level only. Each
Firepower Management Center can have only one AMP for Networks connection.

Cisco AMP Private Cloud

The Firepower Management Center must connect to the AMP cloud for disposition queries for files detected
in network traffic and receipt of retrospective malware events. This cloud can be public or private.
Your organization may have privacy or security concerns that make frequent or direct connections between
your monitored network and the AMP cloud difficult or impossible. In these situations, you can set up a Cisco
AMP Private Cloud, a proprietary Cisco product that acts as a compressed, on-premises version of the AMP

Firepower Management Center Configuration Guide, Version 6.3

1556
 Advanced Malware Protection (AMP) and File Control
Connecting to an AMP Private Cloud

cloud, as well as a secure mediator between your network and the AMP cloud. Connecting a Firepower
Management Center to an AMP private cloud disables existing direct connections to the public AMP cloud.
All connections to the AMP cloud funnel through the AMP private cloud, which acts as an anonymized proxy
to ensure the security and privacy of your monitored network. This includes disposition queries for files
detected in network traffic, receiving of retrospective malware events, and so on. The AMP private cloud
does not share any of your endpoint data over an external connection.

Note The AMP private cloud does not perform dynamic analysis, nor does it support anonymized retrieval of threat
intelligence for other features that rely on Cisco Collective Security Intelligence (CSI), such as URL and
Security Intelligence filtering.

For information about AMP private cloud (sometimes referred to as "AMPv"), see https://www.cisco.com/c/
en/us/products/security/fireamp-private-cloud-virtual-appliance/index.html.

Connecting to an AMP Private Cloud

Smart License Classic License Supported Devices Supported Domains Access

Malware (AMP for Malware (AMP for Any Any Admin

Networks) Networks)
Any (AMP for Any (AMP for
Endpoints) Endpoints)

Before you begin

• Configure your Cisco AMP private cloud or clouds according to the directions in the documentation for
that product. During configuration, note the private cloud host name. You will need this host name in
order to to configure the connection on the Firepower Management Center.
• Make sure the Firepower Management Center can communicate with the AMP private cloud, and confirm
that the private cloud has internet access so it can communicate with the public AMP cloud. See the
topics under Security, Internet Access, and Communication Ports, on page 2679.

Procedure

Step 1 Choose AMP > AMP Management.

Step 2 Click Create AMP Cloud Connection.
Step 3 From the Cloud Name drop-down list, choose Private Cloud.
Step 4 Enter a Name.
This information appears in malware events that are generated or transmitted by AMP private cloud.

Step 5 In the Host field, enter the private cloud host name that you configured when you set up the private cloud.
Step 6 Click Browse next to the Certificate Upload Path field to browse to the location of a valid TLS or SSL
encryption certificate for the private cloud. For more information, see the AMP private cloud documentation.
Step 7 If you want to use this private cloud for both AMP for Networks and AMP for Endpoints, select the Use for
AMP for Firepower check box.

Firepower Management Center Configuration Guide, Version 6.3

1557
 Advanced Malware Protection (AMP) and File Control
Managing Connections to the AMP Cloud (Public or Private)

If you configured a different private cloud to handle AMP for Networks communications, you can clear this
check box; if this is your only AMP private cloud connection, you cannot.
In a multidomain deployment, this check box appears only in the Global domain. Each Firepower Management
Center can have only one AMP for Networks connection.

Step 8 To communicate with the AMP private cloud using a proxy, check the Use Proxy for Connection check box.
Step 9 Click Register, confirm that you want to disable existing direct connections to the AMP cloud, and finally
confirm that you want to continue to the AMP private cloud management console to complete registration.
Step 10 Log into the management console and complete the registration process. For further instructions, see the AMP
private cloud documentation.

What to do next
In high availability configurations, you must configure AMP cloud connections independently on the Active
and Standby instances of the Firepower Management Center; these configurations are not synchronized.

Managing Connections to the AMP Cloud (Public or Private)

Smart License Classic License Supported Devices Supported Domains Access

Malware (AMP for Malware (AMP for Any Any Admin

Networks) Networks)
Any (AMP for Any (AMP for
Endpoints) Endpoints)

Use the Firepower Management Center to manage connections to public and private AMP clouds used for
AMP for Networks or AMP for Endpoints or both.
You can delete a connection to a public or private AMP cloud if you no longer want to receive malware-related
information from the cloud. Note that deregistering a connection using the AMP for Endpoints or AMP private
cloud management console does not remove the connection from the system. Deregistered connections display
a failed state on the Firepower Management Center web interface.
You can also temporarily disable a connection. When you reenable a cloud connection, the cloud resumes
sending data to the system, including queued data from the disabled period.

Caution For disabled connections, the public or private AMP cloud can store malware events, indications of compromise,
and so on until you re-enable the connection. In rare cases—for example, with a very high event rate or a
long-term disabled connection—the cloud may not be able to store all information generated while the
connection is disabled.

In a multidomain deployment, the system displays connections created in the current domain, which you can
manage. It also displays connections created in ancestor domains, which you cannot manage. To manage
connections in a lower domain, switch to that domain. Each Firepower Management Center can have only
one AMP for Networks connection, which belongs to the Global domain.

Firepower Management Center Configuration Guide, Version 6.3

1558
 Advanced Malware Protection (AMP) and File Control
Dynamic Analysis Connections

Procedure

Step 1 Select AMP > AMP Management.

Step 2 Manage your AMP cloud connections:

• Delete — Click the delete icon ( ), then confirm your choice.

• Enable or Disable — Click the slider, then confirm your choice.

What to do next
In high availability configurations, you must configure AMP cloud connections independently on the Active
and Standby instances of the Firepower Management Center; these configurations are not synchronized.

Dynamic Analysis Connections

Requirements for Dynamic Analysis
With the appropriate license, the Firepower system automatically has access to the Cisco Threat Grid public
cloud.
Dynamic analysis requires that managed devices have direct or proxied access to the Cisco Threat Grid public
cloud or an on-premises Cisco Threat Grid appliance on port 443.
See also Which Files Are Eligible for Dynamic Analysis?, on page 1549.

Viewing the Default Dynamic Analysis Connection

Smart License Classic License Supported Devices Supported Domains Access

Malware Malware Any Global only Admin/Access

Admin/Network
Admin

By default, the Firepower Management Center can connect to the public Cisco Threat Grid cloud for file
submission and report retrieval. You can neither configure nor delete this connection.

Procedure

Step 1 Choose AMP > Dynamic Analysis Connections.

Step 2 Click the edit icon ( ).

Note
For information about the button on the AMP > Dynamic Analysis Connections page, see
Enabling Access to Dynamic Analysis Results in the Public Cloud, on page 1561.

Firepower Management Center Configuration Guide, Version 6.3

1559
 Advanced Malware Protection (AMP) and File Control
Dynamic Analysis On-Premises Appliance (Cisco Threat Grid)

Dynamic Analysis On-Premises Appliance (Cisco Threat Grid)

If your organization has privacy or security concerns around submitting files to the public Cisco Threat Grid
cloud, you can deploy an on-premises Cisco Threat Grid appliance. Like the public cloud, the on-premises
appliance runs eligible files in a sandbox environment, and returns a threat score and dynamic a