Asdm 75 Firewall Config

ASDM Book 2: Cisco ASA Series Firewall ASDM Configuration Guide,
7.5
First Published: March 20, 2015
Last Modified: March 20, 2015
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.
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: http://
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. (1110R)
© 2005-2015 Cisco Systems, Inc. All rights reserved.

CONTENTS
Preface About This Guide xvii

Document Objectives xvii
Related Documentation xvii
Document Conventions xvii
Obtaining Documentation and Submitting a Service Request xix
CHAPTER 1 Introduction to Cisco ASA Firewall Services 1

How to Implement Firewall Services 1
Basic Access Control 2
Application Filtering 2
URL Filtering 3
Threat Protection 3
Network Address Translation 4
Application Inspection 4
Use Case: Expose a Server to the Public 5
PART I Access Control 9
CHAPTER 2 Access Rules 11

Controlling Network Access 11
General Information About Rules 12
Interface Access Rules and Global Access Rules 12
Inbound and Outbound Rules 12
Rule Order 13
Implicit Permits 13
Implicit Deny 14
NAT and Access Rules 14
ASDM Book 2: Cisco ASA Series Firewall ASDM Configuration Guide, 7.5
iii
Contents
Extended Access Rules 14

Extended Access Rules for Returning Traffic 14
Allowing Broadcast and Multicast Traffic through the Transparent Firewall Using
Access Rules 14
Management Access Rules 15
EtherType Rules 15
Supported EtherTypes and Other Traffic 15
EtherType Rules for Returning Traffic 16
Allowing MPLS 16
Guidelines for Access Control 16
Configure Access Control 17
Configure Access Rules 17
Access Rule Properties 18
Configure Advanced Options for Access Rules 21
Configure Management Access Rules 23
Configure EtherType Rules (Transparent Mode Only) 24
Configure ICMP Access Rules 25
Monitoring Access Rules 26
Evaluating Syslog Messages for Access Rules 26
History for Access Rules 27
CHAPTER 3 Objects for Access Control 29

Guidelines for Objects 29
Configure Objects 30
Configure Network Objects and Groups 30
Configure a Network Object 30
Configure a Network Object Group 31
Configure Service Objects and Service Groups 31
Configure a Service Object 31
Configure a Service Group 32
Configure Local User Groups 33
Configure Security Group Object Groups 34
Configure Time Ranges 35
Monitoring Objects 36
History for Objects 36
iv
Contents
CHAPTER 4 Access Control Lists 37

About ACLs 37
ACL Types 37
The ACL Manager 39
ACL Names 39
Access Control Entry Order 39
Permit/Deny vs. Match/Do Not Match 40
Access Control Implicit Deny 40
IP Addresses Used for Extended ACLs When You Use NAT 40
Time-Based ACEs 41
Guidelines for ACLs 41
Configure ACLs 42
Configure Extended ACLs 42
Extended ACE Properties 43
Service Specifications in Extended ACEs 46
Configure Standard ACLs 47
Configure Webtype ACLs 48
Webtype ACE Properties 49
Examples for Webtype ACLs 51
Monitoring ACLs 51
History for ACLs 51
CHAPTER 5 Identity Firewall 55

About the Identity Firewall 55
Architecture for Identity Firewall Deployments 56
Features of the Identity Firewall 57
Deployment Scenarios 58
Guidelines for the Identity Firewall 61
Prerequisites for the Identity Firewall 63
Configure the Identity Firewall 64
Configure the Active Directory Domain 65
Configure Active Directory Server Groups 65
Configure Active Directory Agents 66
Configure Active Directory Agent Groups 66
v
Contents
Configure Identity Options 67

Configure Identity-Based Security Policy 69
Monitoring the Identity Firewall 70
History for the Identity Firewall 70
CHAPTER 6 ASA and Cisco TrustSec 73

About Cisco TrustSec 73
About SGT and SXP Support in Cisco TrustSec 74
Roles in the Cisco TrustSec Feature 75
Security Group Policy Enforcement 75
How the ASA Enforces Security Group-Based Policies 76
Effects of Changes to Security Groups on the ISE 77
Speaker and Listener Roles on the ASA 78
Register the ASA with the ISE 79
Create a Security Group on the ISE 80
Generate the PAC File 80
Guidelines for Cisco TrustSec 80
Configure the ASA to Integrate with Cisco Trustsec 83
Configure the AAA Server for Cisco TrustSec Integration 84
Import a PAC File 85
Configure the Security Exchange Protocol 86
Add an SXP Connection Peer 87
Refresh Environment Data 88
Configure the Security Policy 88
Configure Layer 2 Security Group Tagging Imposition 89
Usage Scenarios 89
Configure a Security Group Tag on an Interface 91
Configure IP-SGT Bindings Manually 91
AnyConnect VPN Support for Cisco TrustSec 92
Connect to a Server for Remote Users 92
Add an SGT to Local Users and Groups 92
Monitoring Cisco TrustSec 93
History for Cisco TrustSec 94
CHAPTER 7 ASA FirePOWER Module 95
vi
Contents
About the ASA FirePOWER Module 95

How the ASA FirePOWER Module Works with the ASA 95
ASA FirePOWER Inline Mode 96
ASA FirePOWER Inline Tap Monitor-Only Mode 97
ASA FirePOWER Passive Monitor-Only Traffic Forwarding Mode 98
ASA FirePOWER Management 99
Compatibility with ASA Features 99
Licensing Requirements for the ASA FirePOWER Module 99
Guidelines for ASA FirePOWER 100
Defaults for ASA FirePOWER 101
Perform Initial ASA FirePOWER Setup 101
Deploy the ASA FirePOWER Module in Your Network 101
Routed Mode 101
ASA 5585-X (Hardware Module) in Routed Mode 101
ASA 5506-X through ASA 5555-X (Software Module) in Routed Mode 102
Transparent Mode 103
ASA 5585-X (Hardware Module) in Transparent Mode 103
ASA 5506-X through ASA 5555-X, ISA 3000 (Software Module) in Transparent
Mode 104
Register the ASA FirePOWER Module with a Management Center 104
Access the ASA FirePOWER CLI 105
Configure ASA FirePOWER Basic Settings 105
Configure the ASA FirePOWER Module for ASDM Management 107
Configure the ASA FirePOWER Module 109
Configure the Security Policy on the ASA FirePOWER Module 109
Redirect Traffic to the ASA FirePOWER Module 109
Configure Inline or Inline Tap Monitor-Only Modes 109
Configure Passive Traffic Forwarding 110
Enable Captive Portal for Active Authentication 111
Managing the ASA FirePOWER Module 112
Install or Reimage the Module 112
Install or Reimage the Software Module 112
Reimage the 5585-X ASA FirePOWER Hardware Module 115
Reset the Password 117
Reload or Reset the Module 118
vii
Contents
Shut Down the Module 118

Uninstall a Software Module Image 119
Session to the Software Module From the ASA 119
Upgrade the System Software 120
Monitoring the ASA FirePOWER Module 120
Showing Module Status 120
Showing Module Statistics 120
Analyzing Operational Behavior (ASDM Management) 121
Monitoring Module Connections 121
History for the ASA FirePOWER Module 122
CHAPTER 8 ASA and Cisco Cloud Web Security 125

Information About Cisco Cloud Web Security 125
User Identity and Cloud Web Security 126
Authentication Keys 126
ScanCenter Policy 126
Directory Groups 127
Custom Groups 127
How Groups and the Authentication Key Interoperate 128
Failover from Primary to Backup Proxy Server 128
Licensing Requirements for Cisco Cloud Web Security 128
Guidelines for Cloud Web Security 129
Configure Cisco Cloud Web Security 130
Configure Communications with the Cloud Web Security Proxy Server 130
Identify Whitelisted Traffic 131
Configure a Service Policy to Send Traffic to Cloud Web Security 133
Configure the User Identity Monitor 138
Configure the Cloud Web Security Policy 139
Monitoring Cloud Web Security 139
Examples for Cisco Cloud Web Security 140
Example Service Policy for Cloud Web Security 140
History for Cisco Cloud Web Security 145
PART II Network Address Translation 147
viii
Contents
CHAPTER 9 Network Address Translation (NAT) 149

Why Use NAT? 149
NAT Basics 150
NAT Terminology 150
NAT Types 150
Network Object NAT and Twice NAT 151
Network Object NAT 151
Twice NAT 151
Comparing Network Object NAT and Twice NAT 152
NAT Rule Order 153
NAT Interfaces 154
Guidelines for NAT 154
Firewall Mode Guidelines for NAT 155
IPv6 NAT Guidelines 155
IPv6 NAT Recommendations 155
Additional Guidelines for NAT 156
Network Object NAT Guidelines for Mapped Address Objects 157
Twice NAT Guidelines for Real and Mapped Address Objects 158
Twice NAT Guidelines for Service Objects for Real and Mapped Ports 159
Dynamic NAT 160
About Dynamic NAT 160
Dynamic NAT Disadvantages and Advantages 161
Configure Dynamic Network Object NAT 161
Configure Dynamic Twice NAT 163
Dynamic PAT 168
About Dynamic PAT 168
Dynamic PAT Disadvantages and Advantages 169
PAT Pool Object Guidelines 169
Configure Dynamic Network Object PAT (Hide) 170
Configure Dynamic Network Object PAT Using a PAT Pool 172
Configure Dynamic Twice PAT (Hide) 175
Configure Dynamic Twice PAT Using a PAT Pool 179
Configure PAT with Port Block Allocation 185
Configure Per-Session PAT or Multi-Session PAT (Version 9.0(1) and Higher) 186
ix
Contents
Static NAT 187

About Static NAT 187
Static NAT with Port Translation 188
One-to-Many Static NAT 189
Other Mapping Scenarios (Not Recommended) 190
Configure Static Network Object NAT or Static NAT-with-Port-Translation 191
Configure Static Twice NAT or Static NAT-with-Port-Translation 194
Identity NAT 199
Configure Identity Network Object NAT 199
Configure Identity Twice NAT 201
Monitoring NAT 206
History for NAT 206
CHAPTER 10 NAT Examples and Reference 211

Examples for Network Object NAT 211
Providing Access to an Inside Web Server (Static NAT) 212
NAT for Inside Hosts (Dynamic NAT) and NAT for an Outside Web Server
(Static NAT) 214
Inside Load Balancer with Multiple Mapped Addresses (Static NAT,
One-to-Many) 218
Single Address for FTP, HTTP, and SMTP (Static NAT-with-Port-Translation) 220
Examples for Twice NAT 224
Different Translation Depending on the Destination (Dynamic Twice PAT) 225
Different Translation Depending on the Destination Address and Port (Dynamic
PAT) 231
Example: Twice NAT with Destination Address Translation 237
NAT in Routed and Transparent Mode 238
NAT in Routed Mode 239
NAT in Transparent Mode 239
Routing NAT Packets 241
Mapped Addresses and Routing 241
Addresses on the Same Network as the Mapped Interface 241
Addresses on a Unique Network 241
The Same Address as the Real Address (Identity NAT) 242
Transparent Mode Routing Requirements for Remote Networks 243
x
Contents
Determining the Egress Interface 243

NAT for VPN 244
NAT and Remote Access VPN 244
NAT and Site-to-Site VPN 246
NAT and VPN Management Access 248
Troubleshooting NAT and VPN 250
DNS and NAT 250
DNS Reply Modification, DNS Server on Outside 251
DNS Reply Modification, DNS Server, Host, and Server on Separate Networks 253
DNS Reply Modification, DNS Server on Host Network 253
DNS64 Reply Modification Using Outside NAT 255
PTR Modification, DNS Server on Host Network 261
PART III Service Policies and Application Inspection 263
CHAPTER 11 Service Policy 265

About Service Policies 265
The Components of a Service Policy 265
Features Configured with Service Policies 267
Feature Directionality 268
Feature Matching Within a Service Policy 269
Order in Which Multiple Feature Actions are Applied 270
Incompatibility of Certain Feature Actions 270
Feature Matching for Multiple Service Policies 271
Guidelines for Service Policies 271
Defaults for Service Policies 272
Default Service Policy Configuration 273
Default Class Maps (Traffic Classes) 273
Configure Service Policies 274
Add a Service Policy Rule for Through Traffic 274
Add a Service Policy Rule for Management Traffic 277
Manage the Order of Service Policy Rules 279
History for Service Policies 280
CHAPTER 12 Getting Started with Application Layer Protocol Inspection 281
xi
Contents
Application Layer Protocol Inspection 281

When to Use Application Protocol Inspection 281
Inspection Policy Maps 282
Replacing an In-Use Inspection Policy Map 282
How Multiple Traffic Classes are Handled 282
Guidelines for Application Inspection 283
Defaults for Application Inspection 284
Default Inspections and NAT Limitations 284
Default Inspection Policy Maps 288
Configure Application Layer Protocol Inspection 288
Configure Regular Expressions 292
Create a Regular Expression 292
Create a Regular Expression Class Map 296
Monitoring Inspection Policies 296
History for Application Inspection 297
CHAPTER 13 Inspection of Basic Internet Protocols 299

DCERPC Inspection 300
DCERPC Overview 300
Configure a DCERPC Inspection Policy Map 300
DNS Inspection 302
Defaults for DNS Inspection 302
Configure DNS Inspection Policy Map 302
FTP Inspection 305
FTP Inspection Overview 305
Strict FTP 305
Configure an FTP Inspection Policy Map 306
HTTP Inspection 309
HTTP Inspection Overview 309
Configure an HTTP Inspection Policy Map 310
ICMP Inspection 313
ICMP Error Inspection 313
ILS Inspection 314
Instant Messaging Inspection 314
IP Options Inspection 316
xii
Contents
Defaults for IP Options Inspection 316

Configure an IP Options Inspection Policy Map 317
IPsec Pass Through Inspection 318
IPsec Pass Through Inspection Overview 318
Configure an IPsec Pass Through Inspection Policy Map 318
IPv6 Inspection 319
Defaults for IPv6 Inspection 319
Configure an IPv6 Inspection Policy Map 319
NetBIOS Inspection 320
PPTP Inspection 321
RSH Inspection 321
SMTP and Extended SMTP Inspection 322
SMTP and ESMTP Inspection Overview 322
Defaults for ESMTP Inspection 323
Configure an ESMTP Inspection Policy Map 323
SNMP Inspection 325
SQL*Net Inspection 326
Sun RPC Inspection 326
Sun RPC Inspection Overview 326
Manage Sun RPC Services 327
TFTP Inspection 328
XDMCP Inspection 328
VXLAN Inspection 329
History for Basic Internet Protocol Inspection 329
CHAPTER 14 Inspection for Voice and Video Protocols 331

CTIQBE Inspection 331
Limitations for CTIQBE Inspection 331
H.323 Inspection 332
H.323 Inspection Overview 332
How H.323 Works 332
H.239 Support in H.245 Messages 333
Limitations for H.323 Inspection 334
Configure H.323 Inspection Policy Map 334
MGCP Inspection 336
xiii
Contents
MGCP Inspection Overview 336

Configure an MGCP Inspection Policy Map 337
RTSP Inspection 338
RTSP Inspection Overview 338
RealPlayer Configuration Requirements 339
Limitations for RSTP Inspection 339
Configure RTSP Inspection Policy Map 340
SIP Inspection 341
SIP Inspection Overview 341
Limitations for SIP Inspection 342
Default SIP Inspection 343
Configure SIP Inspection Policy Map 343
Skinny (SCCP) Inspection 345
SCCP Inspection Overview 346
Supporting Cisco IP Phones 346
Limitations for SCCP Inspection 346
Default SCCP Inspection 347
Configure a Skinny (SCCP) Inspection Policy Map 347
History for Voice and Video Protocol Inspection 348
CHAPTER 15 Inspection for Mobile Networks 351

Mobile Network Inspection Overview 351
GTP Inspection Overview 351
Stream Control Transmission Protocol (SCTP) Inspection and Access Control 352
SCTP Stateful Inspection 353
SCTP Access Control 354
SCTP NAT 354
SCTP Application Layer Inspection 354
Diameter Inspection 354
RADIUS Accounting Inspection Overview 355
Licensing for Mobile Network Protocol Inspection 356
Defaults for GTP Inspection 356
Configure Mobile Network Inspection 357
Configure a GTP Inspection Policy Map 357
Configure an SCTP Inspection Policy Map 359
xiv
Contents
Configure a Diameter Inspection Policy Map 361

Create a Custom Diameter Attribute-Value Pair (AVP) 363
Configure the Mobile Network Inspection Service Policy 364
Configure RADIUS Accounting Inspection 365
Configure a RADIUS Accounting Inspection Policy Map 365
Configure the RADIUS Accounting Inspection Service Policy 366
Monitoring Mobile Network Inspection 366
Monitoring GTP Inspection 367
Monitoring SCTP 368
Monitoring Diameter 369
History for Mobile Network Inspection 369
PART IV Connection Management and Threat Detection 371
CHAPTER 16 Connection Settings 373

What Are Connection Settings? 373
Configure Connection Settings 374
Configure Global Timeouts 375
Protect Servers from a SYN Flood DoS Attack (TCP Intercept) 377
Customize Abnormal TCP Packet Handling (TCP Maps, TCP Normalizer) 379
Bypass TCP State Checks for Asynchronous Routing (TCP State Bypass) 381
The Asynchronous Routing Problem 381
Guidelines for TCP State Bypass 382
Configure TCP State Bypass 383
Disable TCP Sequence Randomization 383
Offload Large Flows 384
Flow Offload Limitations 385
Configure Flow Offload 386
Configure Connection Settings for Specific Traffic Classes (All Services) 387
Monitoring Connections 389
History for Connection Settings 390
CHAPTER 17 Quality of Service 393

About QoS 393
Supported QoS Features 393
xv
Contents
What is a Token Bucket? 394

Policing 394
Priority Queuing 394
How QoS Features Interact 395
DSCP (DiffServ) Preservation 395
Guidelines for QoS 395
Configure QoS 396
Determine the Queue and TX Ring Limits for a Priority Queue 396
Queue Limit Worksheet 396
TX Ring Limit Worksheet 397
Configure the Priority Queue for an Interface 397
Configure a Service Rule for Priority Queuing and Policing 398
Monitor QoS 399
QoS Police Statistics 399
QoS Priority Statistics 400
QoS Priority Queue Statistics 400
History for QoS 401
CHAPTER 18 Threat Detection 403

Detecting Threats 403
Basic Threat Detection Statistics 404
Advanced Threat Detection Statistics 404
Scanning Threat Detection 405
Guidelines for Threat Detection 405
Defaults for Threat Detection 406
Configure Threat Detection 407
Configure Basic Threat Detection Statistics 407
Configure Advanced Threat Detection Statistics 407
Configure Scanning Threat Detection 408
Monitoring Threat Detection 409
Monitoring Basic Threat Detection Statistics 409
Monitoring Advanced Threat Detection Statistics 409
History for Threat Detection 410
xvi
About This Guide
The following topics explain how to use this guide.
• Document Objectives, page xvii

• Related Documentation, page xvii
• Document Conventions, page xvii
• Obtaining Documentation and Submitting a Service Request, page xix
Document Objectives
The purpose of this guide is to help you configure the firewall features for the Cisco ASA series using the
Adaptive Security Device Manager (ASDM). This guide does not cover every feature, but describes only the
most common configuration scenarios.
Throughout this guide, the term “ASA” applies generically to supported models, unless specified otherwise.
Note ASDM supports many ASA versions. The ASDM documentation and online help includes all of the latest
features supported by the ASA. If you are running an older version of ASA software, the documentation
might include features that are not supported in your version. Please refer to the feature history table for
each chapter to determine when features were added. For the minimum supported version of ASDM for
each ASA version, see Cisco ASA Series Compatibility.
Related Documentation
For more information, see Navigating the Cisco ASA Series Documentation at http://www.cisco.com/go/
asadocs.
Document Conventions
This document adheres to the following text, display, and alert conventions.
xvii
About This Guide
Document Conventions
Text Conventions
Convention Indication
boldface Commands, keywords, button labels, field names, and user-entered text appear
in boldface. For menu-based commands, the full path to the command is shown.
italic Variables, for which you supply values, are presented in an italic typeface.
Italic type is also used for document titles, and for general emphasis.
monospace Terminal sessions and information that the system displays appear in monospace
type.
{x | y | z} Required alternative keywords are grouped in braces and separated by vertical

bars.
[] Elements in square brackets are optional.
[x | y | z] Optional alternative keywords are grouped in square brackets and separated by

vertical bars.
[] Default responses to system prompts are also in square brackets.
<> Non-printing characters such as passwords are in angle brackets.
!, # An exclamation point (!) or a number sign (#) at the beginning of a line of code
indicates a comment line.
Reader Alerts
This document uses the following for reader alerts:
Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the
manual.
Tip Means the following information will help you solve a problem.
Caution Means reader be careful. In this situation, you might do something that could result in equipment damage
or loss of data.
Timesaver Means the described action saves time. You can save time by performing the action described in the
paragraph.
xviii
About This Guide
Obtaining Documentation and Submitting a Service Request
Warning Means reader be warned. In this situation, you might perform an action that could result in bodily
injury.

For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service
request, and gathering additional information, see What's New in Cisco Product Documentation, at: http://
www.cisco.com/c/en/us/td/docs/general/whatsnew/whatsnew.html.
To receive new and revised Cisco technical content directly to your desktop, you can subscribe to the What's
New in Cisco Product Documentation RSS feed. RSS feeds are a free service.
xix
About This Guide
xx
CHAPTER 1
Introduction to Cisco ASA Firewall Services
Firewall services are those ASA features that are focused on controlling access to the network, including
services that block traffic and services that enable traffic flow between internal and external networks. These
services include those that protect the network against threats, such as Denial of Service (DoS) and other
attacks.
The following topics provide an overview of firewall services.
• How to Implement Firewall Services, page 1

• Basic Access Control, page 2
• Application Filtering, page 2
• URL Filtering, page 3
• Threat Protection, page 3
• Network Address Translation, page 4
• Application Inspection, page 4
• Use Case: Expose a Server to the Public, page 5
How to Implement Firewall Services

The following procedure provides a general sequence for implementing firewall services. However, each step
is optional, needed only if you want to provide the service to your network.
Before You Begin

Configure the ASA according to the general operations configuration guide, including at minimum basic
settings, interface configuration, routing, and management access.
1
Basic Access Control
Procedure
Step 1 Implement access control for the network. See Basic Access Control, on page 2.
Step 2 Implement application filtering. See Application Filtering, on page 2.
Step 3 Implement URL filtering. See URL Filtering, on page 3.
Step 4 Implement threat protection. See Threat Protection, on page 3.
Step 5 Implement Network Address Translation (NAT). See Network Address Translation, on page 4.
Step 6 Implement application inspection if the default settings are insufficient for your network. See Application
Inspection, on page 4.
Basic Access Control

Access rules, applied per interface or globally, are your first line of defense. You can drop, upon entry, specific
types of traffic, or traffic from (or to) specific hosts or networks. By default, the ASA allows traffic to flow
freely from an inside network (higher security level) to an outside network (lower security level).
You can apply an access rule to limit traffic from inside to outside, or allow traffic from outside to inside.
Basic access rules control traffic using a “5-tuple” of source address and port, destination address and port,
and protocol. See Access Rules, on page 11 and Access Control Lists, on page 37.
You can augment your rules by making them identity aware. This lets you configure rules based on user
identity or group membership. To implement identity control, do any combination of the following:
• Install Cisco Context Directory Agent (CDA), also known as AD agent, on a separate server to collect
user and group information already defined in your Active Directory (AD) server. Then, configure the
ASA to get this information, and add user or group criteria to your access rules. See Identity Firewall,
on page 55.
• Install Cisco Identity Services Engine (ISE) on a separate server to implement Cisco Trustsec. You can
then add security group criteria to your access rules. See ASA and Cisco TrustSec, on page 73.
• Install the ASA FirePOWER module on the ASA and implement identity policies in the module. The
identity-aware access policies in ASA FirePOWER would apply to any traffic that you redirect to the
module. See ASA FirePOWER Module, on page 95.
Application Filtering
The wide-spread use of web-based applications means that a lot of traffic runs over the HTTP or HTTPS
protocols. With traditional 5-tuple access rules, you either allow or disallow all HTTP/HTTPS traffic. You
might require more granular control of web traffic.
You can install a module on the ASA to provide application filtering to selectively allow HTTP or other traffic
based on the application being used. Thus, you do not have to make a blanket permit for HTTP. You can look
inside the traffic and prevent applications that are unacceptable for your network (for example, inappropriate
file sharing). When you add a module for application filtering, do not configure HTTP inspection on the ASA.
2
URL Filtering
To implement application filtering, install the ASA FirePOWER module on the ASA and use application
filtering criteria in your ASA FirePOWER access rules. These policies apply to any traffic that you redirect
to the module. See ASA FirePOWER Module, on page 95.
URL Filtering
URL filtering denies or allows traffic based on the URL of the destination site.
The purpose of URL filtering is primarily to completely block or allow access to a web site. Although you
can target individual pages, you typically specify a host name (such as www.example.com) or a URL category,
which defines a list of host names that provide a particular type of service (such as Gambling).
When trying to decide whether to use URL filtering or application filtering for HTTP/HTTPS traffic, consider
whether your intention is to create a policy that applies to all traffic directed at a web site. If your intention
is to treat all such traffic the same way (denying it or allowing it), use URL filtering. If your intention is to
selectively block or allow traffic to the site, use application filtering.
To implement URL filtering, do one of the following:
• Install the ASA FirePOWER module on the ASA and use URL filtering criteria in your ASA FirePOWER
access rules. These policies apply to any traffic that you redirect to the module. See ASA FirePOWER
Module, on page 95.
• Subscribe to the Cloud Web Security service, where you configure your filtering policies in ScanCenter,
and then configure the ASA to send traffic to your Cloud Web Security account. ASA and Cisco Cloud
Web Security, on page 125
Threat Protection
You can implement a number of measures to protect against scanning, denial of service (DoS), and other
attacks. A number of ASA features help protect against attacks by applying connection limits and dropping
abnormal TCP packets. Some features are automatic, others are configurable but have defaults appropriate in
most cases, while others are completely optional and you must configure them if you want them.
Following are the threat protection services available with the ASA.
• IP packet fragmentation protection—The ASA performs full reassembly of all ICMP error messages
and virtual reassembly of the remaining IP fragments that are routed through the ASA, and drops
fragments that fail the security check. No configuration is necessary.
• Connection limits, TCP normalization, and other connection-related features—Configure
connection-related services such as TCP and UDP connection limits and timeouts, TCP sequence number
randomization, TCP normalization, and TCP state bypass. TCP normalization is designed to drop packets
that do not appear normal. See Connection Settings, on page 373.
For example, you can limit TCP and UDP connections and embryonic connections (a connection request
that has not finished the necessary handshake between source and destination). Limiting the number of
connections and embryonic connections protects you from a DoS attack. The ASA uses the embryonic
limit to trigger TCP Intercept, which protects inside systems from a DoS attack perpetrated by flooding
an interface with TCP SYN packets.
• Threat detection—Implement threat detection on the ASA to collect statistics to help identify attacks.
Basic threat detection is enabled by default, but you can implement advanced statistics and scanning
3
Network Address Translation
threat detection. You can shun hosts that are identified as a scanning threat. See Threat Detection, on
page 403.
• Next-Generation IPS—Install the ASA FirePOWER module on the ASA and implement Next Generation
IPS intrusion rules in your ASA FirePOWER. These policies would apply to any traffic that you redirect
to ASA FirePOWER. See ASA FirePOWER Module, on page 95.

One of the main functions of Network Address Translation (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 you can advertise at a minimum only one public address for
the entire network to the outside world.
Other functions of NAT include:
• Security—Keeping internal IP addresses hidden discourages direct attacks.
• IP routing solutions—Overlapping IP addresses are not a problem when you use NAT.
• Flexibility—You can change internal IP addressing schemes without affecting the public addresses
available externally; for example, for a server accessible to the Internet, you can maintain a fixed IP
address for Internet use, but internally, you can change the server address.
• Translating between IPv4 and IPv6 (Routed mode only)—If you want to connect an IPv6 network to
an IPv4 network, NAT lets you translate between the two types of addresses.
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.
See:
• Network Address Translation (NAT), on page 149
• NAT Examples and Reference, on page 211
Application Inspection
Application inspection engines are required for services that embed IP addressing information in the user data
packet or that open secondary channels on dynamically assigned ports. These protocols require the ASA to
do a deep packet inspection, to open the required pinholes and to apply network address translation (NAT).
The default ASA policy already applies inspection globally for many popular protocols, such as DNS, FTP,
SIP, ESMTP, TFTP, and others. The default inspections might be all you require for your network.
However, you might need to enable inspection for other protocols, or fine-tune an inspection. Many inspections
include detailed options that let you control packets based on their contents. If you know a protocol well, you
can apply fine-grained control on that traffic.
You use service policies to configure application inspection. You can configure a global service policy, or
apply a service policy to each interface, or both.
See:
4
Use Case: Expose a Server to the Public
• Service Policy, on page 265

• Getting Started with Application Layer Protocol Inspection, on page 281
• Inspection of Basic Internet Protocols, on page 299
• Inspection for Voice and Video Protocols, on page 331
• Inspection of Database, Directory, and Management Protocols

You can make certain application services on a server available to the public. For example, you could expose
a web server, so that users can connect to the web pages but not make any other connections to the server.
To expose a server to the public, you typically need to create access rules that allow the connection and NAT
rules to translate between the server’s internal IP address and an external address that the public can use. In
addition, you can use port address translation (PAT) to map an internal port to an external port, if you do not
want the externally exposed service to use the same port as the internal server. For example, if the internal
web server is not running on TCP/80, you can map it to TCP/80 to make connections easier for external users.
The following example makes a web server on the inside private network available for public access.
Figure 1: Static NAT for an Inside Web Server
ASDM includes a short cut for configuring the required access and NAT rules, to simplify the process of
exposing a service on an internal server to the public.
5
Procedure
Step 1 Choose Configuration > Firewall > Public Servers.

Step 2 Click Add.
Step 3 Define the private and public characteristics of the service you are exposing.
• Private Interface—The interface to which the real server is connected. In this example, “inside.”
• Private IP Address—The host network object that defines the real IPv4 address of the server. You
cannot specify an IPv6 address. If you do not already have an object containing the address, create one
by clicking the “...” button and then clicking Add. In this example, the object name would be MyWebServ,
and it would contain the 10.1.2.27 host address.
• Private Service—The actual service that is running on the real server. You can use a pre-defined service
or service object. You can also use a service object group unless you also specify a public service to
which you are mapping the private service.
You can expose multiple services; however, if you specify a public service, all ports are mapped to the
same public port.
In this example, the port is tcp/http.
• Public Interface—The interface through which outside users can access the real server. In this example,
“outside.”
• Public Address—The IPv4 address that is seen by outside users. You can specify the address directly
or use a host network object. In this example, the outside address is 209.165.201.10.
• Specify Public Service if different from private service, Public Service—The service that is running
on the translated address. Specify the public service only if it differs from the private service. For example,
if the private web server runs on TCP/80, and you want to use the same port for external users, there is
no need to specify the public service. You must use a pre-defined TCP or UDP service if you specify a
public service. This example does not use port translation, so do not select this option.
The following shows how the dialog box should look.
6
Step 4 Click OK, then click Apply.
7
8
PART I
Access Control
• Access Rules, page 11
• Objects for Access Control, page 29
• Access Control Lists, page 37
• Identity Firewall, page 55
• ASA and Cisco TrustSec, page 73
• ASA FirePOWER Module, page 95
• ASA and Cisco Cloud Web Security, page 125
CHAPTER 2
Access Rules
This chapter describes how to control network access through or to the ASA using access rules. You use
access rules to control network access in both routed and transparent firewall modes. In transparent mode,
you can use both access rules (for Layer 3 traffic) and EtherType rules (for Layer 2 traffic).
Note To access the ASA interface for management access, you do not also need an access rule allowing the
host IP address. You only need to configure management access according to the general operations
configuration guide.
• Controlling Network Access, page 11

• Guidelines for Access Control, page 16
• Configure Access Control, page 17
• Monitoring Access Rules, page 26
• History for Access Rules, page 27
Controlling Network Access

Access rules determine which traffic is allowed through the ASA. There are several different layers of rules
that work together to implement your access control policy:
• Extended access rules (Layer 3+ traffic) assigned to interfaces—You can apply separate rule sets (ACLs)
in the inbound and outbound directions. An extended access rule permits or denies traffic based on the
source and destination traffic criteria.
• Extended access rules assigned globally—You can create a single global rule set, which serves as your
default access control. The global rules are applied after interface rules.
• Management access rules (Layer 3+ traffic)—You can apply a single rule set to cover traffic directed
at an interface, which would typically be management traffic. In the CLI, these are “control plane” access
groups. For ICMP traffic directed at the device, you can alternatively configure ICMP rules.
11
• EtherType rules (Layer 2 traffic) assigned to interfaces (transparent firewall mode only)—You can apply
separate rule sets in the inbound and outbound directions. EtherType rules control network access for
non-IP traffic. An EtherType rule permits or denies traffic based on the EtherType.
In transparent firewall mode, you can combine extended access rules, management access rules, and EtherType
rules on the same interface.
General Information About Rules

The following topics provide general information about access rules and EtherType rules.
Interface Access Rules and Global Access Rules

You can apply an access rule to a specific interface, or you can apply an access rule globally to all interfaces.
You can configure global access rules in conjunction with interface access rules, in which case, the specific
inbound interface access rules are always processed before the general global access rules. Global access rules
apply only to inbound traffic.
Inbound and Outbound Rules

You can configure access rules based on the direction of traffic:
• Inbound—Inbound access rules apply to traffic as it enters an interface. Global and management access
rules are always inbound.
• Outbound—Outbound rules apply to traffic as it exits an interface.
Note “Inbound” and “outbound” refer to the application of an ACL on an interface, either to traffic entering the
ASA on an interface or traffic exiting the ASA on an interface. These terms do not refer to the movement
of traffic from a lower security interface to a higher security interface, commonly known as inbound, or
from a higher to lower interface, commonly known as outbound.
An outbound ACL is useful, for example, if you want to allow only certain hosts on the inside networks to
access a web server on the outside network. Rather than creating multiple inbound ACLs to restrict access,
12
you can create a single outbound ACL that allows only the specified hosts. (See the following figure.) The
outbound ACL prevents any other hosts from reaching the outside network.
Figure 2: Outbound ACL
Rule Order
The order of rules is important. When the ASA decides whether to forward or drop a packet, the ASA tests
the packet against each rule in the order in which the rules are listed in the applied ACL. After a match is
found, no more rules are checked. For example, if you create an access rule at the beginning that explicitly
permits all traffic for an interface, no further rules are ever checked.
Implicit Permits
For routed mode, the following types of traffic are allowed through by default:
• Unicast IPv4 and IPv6 traffic from a higher security interface to a lower security interface.
For transparent mode, the following types of traffic are allowed through by default:
• Unicast IPv4 and IPv6 traffic from a higher security interface to a lower security interface.
• ARPs in both directions. (You can control ARP traffic using ARP inspection, but you cannot control it
by access rule.)
• BPDUs in both directions.
13
For other traffic, you need to use either an extended access rule (IPv4 and IPv6) or an EtherType rule (non-IP).
Implicit Deny
ACLs have an implicit deny at the end of the list, so unless you explicitly permit it, traffic cannot pass. For
example, if you want to allow all users to access a network through the ASA except for particular addresses,
then you need to deny the particular addresses and then permit all others.
For EtherType ACLs, the implicit deny at the end of the ACL does not affect IP traffic or ARPs; for example,
if you allow EtherType 8037, the implicit deny at the end of the ACL does not now block any IP traffic that
you previously allowed with an extended ACL (or implicitly allowed from a high security interface to a low
security interface). However, if you explicitly deny all traffic with an EtherType rule, then IP and ARP traffic
is denied; only physical protocol traffic, such as auto-negotiation, is still allowed.
If you configure a global access rule, then the implicit deny comes after the global rule is processed. See the
following order of operations:
1 Interface access rule.
2 Global access rule.
3 Implicit deny.
NAT and Access Rules

Access rules always use the real IP addresses when determining an access rule match, even if you configure
NAT. For example, if you configure NAT for an inside server, 10.1.1.5, so that it has a publicly routable IP
address on the outside, 209.165.201.5, then the access rule to allow the outside traffic to access the inside
server needs to reference the server’s real IP address (10.1.1.5), and not the mapped address (209.165.201.5).
Extended Access Rules

This section describes information about extended access rules.
Extended Access Rules for Returning Traffic

For TCP, UDP, and SCTP connections for both routed and transparent mode, you do not need an access rule
to allow returning traffic because the ASA allows all returning traffic for established, bidirectional connections.
For connectionless protocols such as ICMP, however, the ASA establishes unidirectional sessions, so you
either need access rules to allow ICMP in both directions (by applying ACLs to the source and destination
interfaces), or you need to enable the ICMP inspection engine. The ICMP inspection engine treats ICMP
sessions as bidirectional connections. For example, to control ping, specify echo-reply (0) (ASA to host) or
echo (8) (host to ASA).
Allowing Broadcast and Multicast Traffic through the Transparent Firewall Using Access Rules
In routed firewall mode, broadcast and multicast traffic is blocked even if you allow it in an access rule,
including unsupported dynamic routing protocols and DHCP (unless you configure DHCP relay). Transparent
firewall mode can allow any IP traffic through.
14
Note Because these special types of traffic are connectionless, you need to apply an access rule to both interfaces,
so returning traffic is allowed through.
The following table lists common traffic types that you can allow through the transparent firewall.
Table 1: Transparent Firewall Special Traffic
Traffic Type Protocol or Port Notes

DHCP UDP ports 67 and 68 If you enable the DHCP server, then the ASA does
not pass DHCP packets.
EIGRP Protocol 88 —
OSPF Protocol 89 —
Multicast streams The UDP ports vary depending on Multicast streams are always destined to a Class D
the application. address (224.0.0.0 to 239.x.x.x).
RIP (v1 or v2) UDP port 520 —
Management Access Rules

You can configure access rules that control management traffic destined to the ASA. Access control rules for
to-the-box management traffic (such as HTTP, Telnet, and SSH connections to an interface) have higher
precedence than a management access rule . Therefore, such permitted management traffic will be allowed
to come in even if explicitly denied by the to-the-box ACL.
Alternatively, you can use ICMP rules to control ICMP traffic to the device. Use regular extended access
rules to control ICMP traffic through the device.
EtherType Rules
This section describes EtherType rules.
Supported EtherTypes and Other Traffic

An EtherType rule controls the following:
• EtherType identified by a 16-bit hexadecimal number, including common types IPX and MPLS unicast
or multicast.
• Ethernet V2 frames.
• BPDUs, which are permitted by default. BPDUs are SNAP-encapsulated, and the ASA is designed to
specifically handle BPDUs.
• Trunk port (Cisco proprietary) BPDUs. Trunk BPDUs have VLAN information inside the payload, so
the ASA modifies the payload with the outgoing VLAN if you allow BPDUs.
15
Guidelines for Access Control
• Intermediate System to Intermediate System (IS-IS).
The following types of traffic are not supported:

• 802.3-formatted frames—These frames are not handled by the rule because they use a length field as
opposed to a type field.
EtherType Rules for Returning Traffic

Because EtherTypes are connectionless, you need to apply the rule to both interfaces if you want traffic to
pass in both directions.
Allowing MPLS
If you allow MPLS, ensure that Label Distribution Protocol and Tag Distribution Protocol TCP connections
are established through the ASA by configuring both MPLS routers connected to the ASA to use the IP address
on the ASA interface as the router-id for LDP or TDP sessions. (LDP and TDP allow MPLS routers to negotiate
the labels (addresses) used to forward packets.)
On Cisco IOS routers, enter the appropriate command for your protocol, LDP or TDP. The interface is the
interface connected to the ASA.
mpls ldp router-id interface force
Or
tag-switching tdp router-id interface force
Guidelines for Access Control

IPv6 Guidelines
Supports IPv6. (9.0 and later) The source and destination addresses can include any mix of IPv4 and IPv6
addresses. For pre-9.0 versions, you must create a separate IPv6 access rule.
Per-User ACL Guidelines

• The per-user ACL uses the value in the timeout uauth command, but it can be overridden by the AAA
per-user session timeout value.
• If traffic is denied because of a per-user ACL, syslog message 109025 is logged. If traffic is permitted,
no syslog message is generated. The log option in the per-user ACL has no effect.
Additional Guidelines and Limitations

• You can reduce the memory required to search access rules by enabling object group search, but this is
at the expense rule of lookup performance. When enabled, object group search does not expand network
objects, but instead searches access rules for matches based on those group definitions. You can set this
option by clicking the Advanced button below the access rule table.
16
Configure Access Control
• You can improve system performance and reliability by using the transactional commit model for access
groups. See the basic settings chapter in the general operations configuration guide for more information.
The option is under Configurations > Device Management > Advanced > Rule Engine.
• In ASDM, rule descriptions are based on the access list remarks that come before the rule in the ACL;
for new rules you create in ASDM, any descriptions are also configured as remarks before the related
rule. However, the packet tracer in ASDM matches the remark that is configured after the matching rule
in the CLI.
• If you enter more than one item in source or destination address, or source or destination service, ASDM
automatically creates an object group for them with the prefix DM_INLINE. These objects are
automatically expanded to their component parts in the rule table view, but you can see the object names
if you deselect the Auto-expand network and service objects with specified prefix rule table preference
in Tools > Preferences.
• Normally, you cannot reference an object or object group that does not exist in an ACL or object group,
or delete one that is currently referenced. You also cannot reference an ACL that does not exist in an
access-group command (to apply access rules). However, you can change this default behavior so that
you can “forward reference” objects or ACLs before you create them. Until you create the objects or
ACLs, any rules or access groups that reference them are ignored. To enable forward referencing, select
the option in the access rules advanced settings; choose Configuration > Access Rules and click the
Advanced button.

The following topics explain how to configure access control.
Configure Access Rules

To apply an access rule, perform the following steps.
Procedure
Step 1 Choose Configuration > Firewall > Access Rules.

The rules are organized by interface and direction, with a separate group for global rules. If you configure
management access rules, they are repeated on this page. These groups are equivalent to the extended ACL
that is created and assigned to the interface or globally as an access group. These ACLs also appear on the
ACL Manager page.
Step 2 Do any of the following:

• To add a new rule, choose Add > Add Access Rule.
• To insert a rule at a specific location within a container, select an existing rule and choose Add > Insert
to add the rule above it, or choose Add > Insert After.
• To edit a rule, select it and click Edit.
Step 3 Fill in the rule properties. The primary options to select are:
• Interface—The interface to which the rule applies. Select Any to create a global rule.
17
• Action: Permit/Deny—Whether you are permitting (allowing) the described traffic or are denying
(dropping) it.
• Source/Destination criteria—A definition of the source (originating address) and destination (target
address of the traffic flow). You typically configure IPv4 or IPv6 addresses of hosts or subnets, which
you can represent with network or network object groups. You can also specify a user or user group
name for the source. Additionally, you can use the Service field to identify the specific type of traffic if
you want to focus the rule more narrowly than all IP traffic. If you implement Trustsec, you can use
security groups to define source and destination.
For detailed information on all of the available options, see Access Rule Properties, on page 18.
When you are finished defining the rule, click OK to add the rule to the table.
Step 4 Click Apply to save the access rule to your configuration.
Access Rule Properties

When you add or edit an access rule, you can configure the following properties. In many fields, you can click
the “...” button on the right of the edit box to select, create, or edit objects that are available for the field.
Interface
The interface to which the rule applies. Select Any to create a global rule.
Action: Permit/Deny
Whether you are permitting (allowing) the described traffic or are denying (dropping) it.
18
Source Criteria
The characteristics of the originator of the traffic you are trying to match. You must configure Source,
but the other properties are optional.
Source
The IPv4 or IPv6 address of the source. The default is any, which matches all IPv4 or IPv6
addresses; you can use any4 to target IPv4 only, or any6 to target IPv6 only. You can specify a
single host address (such as 10.100.10.5 or 2001:DB8::0DB8:800:200C:417A), 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), the
name of a network object or network object group, or the name of an interface.
User
If you enable the identity firewall, you can specify a user or user group as the traffic source. The
IP address the user is currently using will match the rule. You can specify a username
(DOMAIN\user), a user group (DOMAIN\\group, note the double \ indicates a group name), or
a user object group. For this field, it is far easier to click “...” to select names from your AAA
server group than to type them in.
Security Group
If you enable Cisco Trustsec, you can specify a security group name or tag (1-65533), or security
group object.
More Options > Source Service

If you specify TCP, UDP, or SCTP as the destination service, you can optionally specify a
predefined service object for TCP, UDP, TCP-UDP, or SCTP, or use your own object. Typically,
you define the destination service only and not the source service. Note that if you define the
source service, the destination service protocol must match it (for example, both TCP, with or
without port definitions).
19
Destination Criteria
The characteristics of the target of the traffic you are trying to match. You must configure Destination,
Destination
The IPv4 or IPv6 address of the destination. The default is any, which matches all IPv4 or IPv6
Security Group
If you enable Cisco Trustsec, you can specify a security group name or tag (1-65533), or security
group object.
Service
The protocol of the traffic, such as IP, TCP, UDP, and optionally ports for TCP, UDP, or SCTP.
The default is IP, but you can select a more specific protocol to target traffic with more granularity.
Typically, you would select some type of service object. For TCP, UDP, and SCTP, you can
specify ports, for example, tcp/80, tcp/http, tcp/10-20 (for a range of ports), tcp-udp/80 (match
any TCP or UDP traffic on port 80), sctp/diameter, and so forth.
Description
A explanation of the purpose of the rule, up to 100 characters per line. You can enter multiple lines;
each line is added as a remark in the CLI, and the remarks are placed before the rule.
Note If you add remarks with non-English characters on one platform (such as
Windows) then try to remove them from another platform (such as Linux), you
might not be able to edit or delete them because the original characters might
not be correctly recognized. This limitation is due to an underlying platform
dependency that encodes different language characters in different ways.
20
Enable Logging; Logging Level; More Options > Logging Interval

The logging options define how syslog messages will be generated for rules. You can implement the
following logging options:
Deselect Enable Logging
This will disable logging for the rule. No syslog messages of any type will be issued for
connections that match this rule.
Select Enable Logging with Logging Level = Default

This provides the default logging for rules. Syslog message 106023 is issued for each denied
connection. If the appliance comes under attack, the frequency of issuing this message could
impact services.
Select Enable Logging with Non-Default Logging Level

This provides a summarized syslog message, 106100, instead of 106023. Message 106100 is
issued upon first hit, then again at each interval configured in More Options > Logging Interval
(default is every 300 seconds, you can specify 1-600), showing the number of hits during that
interval. The recommended logging level is Informational.
Summarizing deny messages can reduce the impact of attacks and possibly make it easier for
you to analyze messages. If you do come under a denial of service attack, you might see message
106101, which indicates that the number of cached deny flows used to produce the hit count for
message 106100 has exceeded the maximum for an interval. At this point, the appliance stops
collecting statistics until the next interval to mitigate the attack.
More Options > Traffic Direction

Whether the rule is for the In or Out direction. In is the default, and it is the only option for global and
management access rules.
More Options > Enable Rule

Whether the rule is active on the device. Disabled rules appear with strike-through text in the rule table.
Disabling a rule lets you stop its application to traffic without deleting it, so you can enable it again
later if you decide you need it.
More Options > Time Range

The name of the time range object that defines the times of day and days of the week when the rule
should be active. If you do not specify a time range, the rule is always active.
Configure Advanced Options for Access Rules

Advanced access rule options allow you to customize certain aspects of rule behavior, but these options have
defaults that are appropriate in most cases.
21
Procedure
Step 1 Choose Configuration > Firewall > Access Rules.

Step 2 Click the Advanced button below the rule table.
Step 3 Configure the following options as required:
• Advanced Logging Settings—If you configure non-default logging, the system caches deny flows to
develop statistics for message 106100, as explained in Evaluating Syslog Messages for Access Rules,
on page 26. To prevent unlimited consumption of memory and CPU resources, the ASA places a limit
on the number of concurrent deny flows because they can indicate an attack. Message 106101 is issued
when the limit is reached. You can control the following aspects related to 106101.
◦Maximum Deny-flows—The maximum number of deny flows permitted before the ASA stops
caching flows, between 1 and 4096. The default is 4096.
◦Alert Interval—The amount of time (1-3600 seconds) between issuing system log message 106101,
which indicates that the maximum number of deny flows was reached. The default is 300 seconds.
• Per User Override table—Whether to allow a dynamic user ACL that is downloaded for user
authorization from a RADIUS server to override the ACL assigned to the interface. For example, if the
interface ACL denies all traffic from 10.0.0.0, but the dynamic ACL permits all traffic from 10.0.0.0,
then the dynamic ACL overrides the interface ACL for that user. Check the Per User Override box for
each interface that should allow user overrides (inbound direction only). If the per user override feature
is disabled, the access rule provided by the RADIUS server is combined with the access rule configured
on that interface.
By default, VPN remote access traffic is not matched against interface ACLs. However, if you deselect
the Enable inbound VPN sessions to bypass interface access lists setting on the Configuration >
Remote Access VPN > Network (Client) Access > AnyConnect Connection Profiles pane), the behavior
depends on whether there is a VPN filter applied in the group policy (see the Configuration > Remote
Access VPN > Network (Client) Access > Group Policies > Add/Edit > General > More Options > Filter
field) and whether you set the Per User Override option:
◦No Per User Override, no VPN filter —Traffic is matched against the interface ACL.
◦No Per User Override, VPN filter —Traffic is matched first against the interface ACL, then against
the VPN filter.
◦Per User Override, VPN filter —Traffic is matched against the VPN filter only.
• Object Group Search Setting—You can reduce the memory required to search access rules that use
object groups by selecting Enable Object Group Search Algorithm, but this is at the expense of rule
lookup performance. When enabled, object group search does not expand network objects, but instead
searches access rules for matches based on those group definitions.
• Forward Reference Setting—Normally, you cannot reference an object or object group that does not
exist in an ACL or object group, or delete one that is currently referenced. You also cannot reference
an ACL that does not exist in an access-group command (to apply access rules). However, you can
change this default behavior so that you can “forward reference” objects or ACLs before you create them.
Until you create the objects or ACLs, any rules or access groups that reference them are ignored. Select
Enable the forward reference of objects and object-groups to enable forward referencing. Be aware
22
that if you enable forward referencing, ASDM cannot tell the difference between a typo reference to an
existing object and a forward reference.
Step 4 Click OK.
Configure Management Access Rules

You can configure an interface ACL that controls to-the-box management traffic from a specific peer (or set
of peers) to the ASA. One scenario in which this type of ACL would be useful is when you want to block
IKE Denial of Service attacks.
Procedure
Step 1 Choose Configuration > Device Management > Management Access > Management Access Rules.
The rules are organized by interface. Each group is equivalent to the extended ACL that is created and assigned
to the interface as a control plane ACL. These ACLs also appear on the Access Rules and ACL Manager
pages.

• To add a new rule, choose Add > Add Management Access Rule.
• Interface—The interface to which the rule applies.
(dropping) it.
you want to focus the rule more narrowly than all IP traffic. If you implement Trustsec, you can use
security groups to define source and destination.
For detailed information on all of the available options, see Access Rule Properties, on page 18.
Step 4 Click Apply to save the rule to your configuration.
23
Configure EtherType Rules (Transparent Mode Only)

EtherType rules apply to non-IP layer-2 traffic in transparent firewall mode. You can use these rules to permit
or drop traffic based on the EtherType value in the layer-2 packet. With EtherType rules, you can control the
flow of non-IP traffic across the ASA.
In transparent mode, you can apply both extended and EtherType access rules to an interface. EtherType rules
take precedence over the extended access rules.
Procedure
Step 1 Choose Configuration > Firewall > EtherType Rules.

The rules are organized by interface and direction. Each group is equivalent to the EtherType ACL that is
created and assigned to the interface.

• To add a new rule, choose Add > Add EtherType Rule.
• Interface—The interface to which the rule applies.
(dropping) it.
• EtherType—You can match traffic using the following options:
◦ipx—Internet Packet Exchange (IPX).
◦bpdu—bridge protocol data units, which are allowed by default.
◦mpls-multicast— MPLS multicast.
◦mpls-unicast—MPLS unicast.
◦isis—Intermediate System to Intermediate System (IS-IS).
◦any—Matches all traffic.
◦hex_number—Any EtherType that can be identified by a 16-bit hexadecimal number 0x600 to
0xffff. See RFC 1700, “Assigned Numbers,” at http://www.ietf.org/rfc/rfc1700.txt for a list of
EtherTypes.
• Description—A explanation of the purpose of the rule, up to 100 characters per line. You can enter
multiple lines; each line is added as a remark in the CLI, and the remarks are placed before the rule.
• More Options > Direction—Whether the rule is for the In or Out direction. In is the default.
24
Step 4 Click Apply to save the rule to your configuration.
Configure ICMP Access Rules

By default, you can send ICMP packets to any interface using either IPv4 or IPv6, with these exceptions:
• The ASA does not respond to ICMP echo requests directed to a broadcast address.
• The ASA 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.
Procedure
Step 1 Choose Configuration > Device Management > Management Access > ICMP.
Step 2 Configure ICMP rules:
a) Add a rule (Add > Rule, Add > IPv6 Rule, or Add > Insert), or select a rule and edit it.
b) Select the ICMP type you want to control, or any to apply to all types.
c) Select the interface to which the rule applies. You must create separate rules for each interface.
d) Select whether you are permitting or denying access for matching traffic.
e) Select Any Address to apply the rule to all traffic. Alternatively, enter the address and mask (for IPv4)
or address and prefix length (for IPv6) of the host or network you are trying to control.
f) Click OK.
Step 3 (Optional) To set ICMP unreachable message limits, set the following options. Increasing the rate limit, along
with enabling the Decrement time to live for a connection option in a service policy (on the Configuration
> Firewall > Service Policy Rules > Rule Actions > Connection Settings dialog box), is required to allow a
trace route through the ASA that shows the ASA as one of the hops.
• 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 4 Click Apply.
25
Monitoring Access Rules
Monitoring Access Rules

The Access Rules page includes hit counts for each rule. Mouse over the hit count to see the update time and
interval for the count. To reset the hit count, right click the rule and select Clear Hit Count, but be aware
that this clears the count for all rules applied to the same interface in the same direction.
Evaluating Syslog Messages for Access Rules

Use a syslog event viewer, such as the one in ASDM, to view messages related to access rules.
If you use default logging, you see syslog message 106023 for explicitly denied flows only. Traffic that
matches the “implicit deny” entry that ends the rule list is not logged.
If the ASA is attacked, the number of syslog messages for denied packets can be very large. We recommend
that you instead enable logging using syslog message 106100, which provides statistics for each rule (including
permit rules) and enables you to limit the number of syslog messages produced. Alternatively, you can disable
all logging for a given rule.
When you enable logging for message 106100, if a packet matches an ACE, the ASA creates a flow entry to
track the number of packets received within a specific interval. The ASA generates a syslog message at the
first hit and at the end of each interval, identifying the total number of hits during the interval and the time
stamp for the last hit. At the end of each interval, the ASA resets the hit count to 0. If no packets match the
ACE during an interval, the ASA deletes the flow entry. When you configure logging for a rule, you can
control the interval and even the severity level of the log message, per rule.
A flow is defined by the source and destination IP addresses, protocols, and ports. Because the source port
might differ for a new connection between the same two hosts, you might not see the same flow increment
because a new flow was created for the connection.
Permitted packets that belong to established connections do not need to be checked against ACLs; only the
initial packet is logged and included in the hit count. For connectionless protocols, such as ICMP, all packets
are logged, even if they are permitted, and all denied packets are logged.
See the syslog messages guide for detailed information about these messages.
Tip When you enable logging for message 106100, if a packet matches an ACE, the ASA creates a flow entry
to track the number of packets received within a specific interval. The ASA has a maximum of 32 K
logging flows for ACEs. A large number of flows can exist concurrently at any point of time. To prevent
unlimited consumption of memory and CPU resources, the ASA places a limit on the number of concurrent
deny flows; the limit is placed on deny flows only (not on permit flows) because they can indicate an
attack. When the limit is reached, the ASA does not create a new deny flow for logging until the existing
flows expire, and issues message 106101. You can control the frequency of this message, and the maximum
number of deny flows cached, in the advanced settings; see Configure Advanced Options for Access
Rules, on page 21.
26
History for Access Rules

Feature Name Platform Releases Description
Interface access rules 7.0(1) Controlling network access through the ASA using ACLs.
We introduced the following screen: Configuration > Firewall > Access
Rules.
Global access rules 8.3(1) Global access rules were introduced.

We modified the following screen: Configuration > Firewall > Access
Rules.
Support for Identity Firewall 8.4(2) You can now use identity firewall users and groups for the source and
destination. You can use an identity firewall ACL with access rules,
AAA rules, and for VPN authentication.
EtherType ACL support for IS-IS traffic 8.4(5), 9.1(2) In transparent firewall mode, the ASA can now pass IS-IS traffic using
an EtherType ACL.
We modified the following screen: Configuration > Device
Management > Management Access > EtherType Rules.
Support for TrustSec 9.0(1) You can now use TrustSec security groups for the source and
destination. You can use an identity firewall ACL with access rules.
Unified ACL for IPv4 and IPv6 9.0(1) ACLs now support IPv4 and IPv6 addresses. You can even specify a
mix of IPv4 and IPv6 addresses for the source and destination. The
any keyword was changed to represent IPv4 and IPv6 traffic. The
any4 and any6 keywords were added to represent IPv4-only and
IPv6-only traffic, respectively. The IPv6-specific ACLs are deprecated.
Existing IPv6 ACLs are migrated to extended ACLs. See the release
notes for more information about migration.
We modified the following screens:
Configuration > Firewall > Access Rules Configuration > Remote
Access VPN > Network (Client) Access > Group Policies > General
> More Options
Extended ACL and object enhancement 9.0(1) ICMP traffic can now be permitted/denied based on ICMP code.
to filter ICMP traffic by ICMP code We introduced or modified the following screens:
Configuration > Firewall > Objects > Service Objects/Groups
Configuration > Firewall > Access Rule
Transactional Commit Model on Access 9.1(5) When enabled, a rule update is applied after the rule compilation is
Group Rule Engine completed; without affecting the rule matching performance.
We introduced the following screen: Configuration > Device
Management > Advanced > Rule Engine.
27

Configuration session for editing ACLs 9.3(2) You can now edit ACLs and objects in an isolated configuration
and objects. session. You can also forward reference objects and ACLs, that is,
configure rules and access groups for objects or ACLs that do not yet
Forward referencing of objects and
exist.
ACLs in access rules.
Access rule support for Stream Control 9.5(2) You can now create access rules using the sctp protocol, including
Transmission Protocol (SCTP) port specifications.
We modified the add/edit dialog boxes for access rules on the
Configuration > Firewall > Access Rules page.
28
CHAPTER 3
Objects for Access Control
Objects are reusable components for use in your configuration. You can define and use them in Cisco ASA
configurations in the place of inline IP addresses, services, names, and so on. Objects make it easy to maintain
your configurations because you can modify an object in one place and have it be reflected in all other places
that are referencing it. Without objects you would have to modify the parameters for every feature when
required, instead of just once. For example, if a network object defines an IP address and subnet mask, and
you want to change the address, you only need to change it in the object definition, not in every feature that
refers to that IP address.
• Guidelines for Objects, page 29

• Configure Objects, page 30
• Monitoring Objects, page 36
• History for Objects, page 36
Guidelines for Objects

IPv6 Guidelines
Supports IPv6 with the following restrictions:
• The ASA does not support IPv6 nested network object groups, so you cannot group an object with IPv6
entries under another IPv6 object group.
• You can mix IPv4 and IPv6 entries in a network object group, but you cannot use a mixed object group
for NAT.

• Objects must have unique names, because objects and object groups share the same name space. While
you might want to create a network object group named “Engineering” and a service object group named
“Engineering,” you need to add an identifier (or “tag”) to the end of at least one object group name to
make it unique. For example, you can use the names “Engineering_admins” and “Engineering_hosts” to
make the object group names unique and to aid in identification.
29
Configure Objects
• Object names are limited to 64 characters, including letters, numbers, and these characters:
.!@#$%^&()-_{}. Object names are case-sensitive.
• You cannot remove an object or make an object empty if it is used in a command, unless you enable
forward referencing (in the access rules advanced settings).
Configure Objects
The following sections describe how to configure objects that are primarily used on access control.
Configure Network Objects and Groups

Network objects and groups identify IP addresses or host names. Use these objects in access control lists to
simplify your rules.
Configure a Network Object

A network object can contain a host, a network IP address, a range of IP addresses, or a fully qualified domain
name (FQDN).
You can also enable NAT rules on the object (excepting FQDN objects). For more information about
configuring object NAT, see Network Address Translation (NAT), on page 149.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Network Objects/Group.
Step 2 Do one of the following:
• Choose Add > Network Object to add a new object. Enter a name and optionally, a description.
• Choose an existing object and click Edit.
Step 3 Configure the address for the object based on the object Type and IP version fields.
• Host—The IPv4 or IPv6 address of a single host. For example, 10.1.1.1 or
2001:DB8::0DB8:800:200C:417A.
• Network—The address of a network. For IPv4, include the mask, for example, IP address = 10.0.0.0
Netmask = 255.0.0.0. For IPv6, include the prefix, such as IP Address = 2001:DB8:0:CD30:: Prefix
Length = 60.
• Range—A range of addresses. You can specify IPv4 or IPv6 ranges. Do not include masks or prefixes.
• FQDN—A fully-qualified domain name, that is, the name of a host, such as www.example.com.

You can now use this network object when you create a rule. If you edit an object, the change is inherited
automatically by any rules using the object.
30
Configure Objects
Configure a Network Object Group

Network object groups can contain multiple network objects as well as inline networks or hosts. Network
object groups can include a mix of both IPv4 and IPv6 addresses.
However, you cannot use a mixed IPv4 and IPv6 object group for NAT, or object groups that include FQDN
objects.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Network Objects/Groups.
• Choose Add > Network Object Group to add a new object. Enter a name and optionally, a description.
Step 3 Add network objects to the group using any combination of the following techniques:
• Existing Network Objects/Groups—Select any already defined network object or group and click
Add to include them in the group.
• Create New Network Object Member—Enter the criteria for a new network object and click Add. If
you give the object a name, when you apply changes, the new object is created and added to the group.
The name is optional when adding hosts or networks.
Step 4 After you add all the member objects, click OK, then click Apply.
You can now use this network object group when you create a rule. For an edited object group, the change is
inherited automatically by any rules using the group.
Configure Service Objects and Service Groups

Service objects and groups identify protocols and ports. Use these objects in access control lists to simplify
your rules.
Configure a Service Object

A service object can contain a single protocol specification.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Service Object/Group.
• Choose Add > Service Object to add a new object. Enter a name and optionally, a description.
31
Configure Objects
Step 3 Choose the service type and fill in details as needed:

• Protocol—A number between 0-255, or a well-known name, such as ip, tcp, udp, gre, and so forth..
• ICMP, ICMP6—You can leave the message type and code fields blank to match any ICMP/ICMP
version 6 message. You can optionally specify the ICMP type by name or number (0-255) to limit the
object to that message type. If you specify a type, you can optionally specify an ICMP code for that type
(1-255). If you do not specify the code, then all codes are used.
• TCP, UDP, SCTP—You can optionally specify ports for the source, destination, or both. You can specify
the port by name or number. You can include the following operators:
◦<—Less than. For example, <80.
◦>—Greater than. For example, >80.
◦!=—Not equal to. For example, !=80.
◦- (hyphen)—An inclusive range of values. For example, 100-200.
Step 4 Click OK, and then Apply.
Configure a Service Group

A service object group includes a mix of protocols, if desired, including optional source and destination ports
for protocols that use them, and ICMP type and code.
Before You Begin

You can model all services using the generic service object group, which is explained here. However, you
can still configure the types of service group objects that were available prior to ASA 8.3(1). These legacy
objects include TCP/UDP/TCP-UDP port groups, protocol groups, and ICMP groups. The contents of these
groups are equivalent to the associated configuration in the generic service object group, with the exception
of ICMP groups, which do not support ICMP6 or ICMP codes. If you still want to use these legacy objects,
for detailed instructions, see the object-service command description in the command reference on Cisco.com.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Service Objects/Groups.
• Choose Add > Service Group to add a new object. Enter a name and optionally, a description.
Step 3 Add service objects to the group using any combination of the following techniques:
• Existing Service/Service Group—Select any already defined service, service object, or group and click
Add to include them in the group.
• Create New Member—Enter the criteria for a new service object and click Add. If you give the object
a name, when you apply changes, the new object is created and added to the group; otherwise, unnamed
32
Configure Objects
objects are members of this group only. You cannot name TCP-UDP objects; these are members of the
group only.
You can now use this service object group when you create a rule. For an edited object group, the change is
Configure Local User Groups

You can create local user groups for use in features that support the identity firewall by including the group
in an extended ACL, which in turn can be used in an access rule, for example.
The ASA sends an LDAP query to the Active Directory server for user groups globally defined in the Active
Directory domain controller. The ASA imports these groups for identity-based rules. However, the ASA might
have localized network resources that are not defined globally that require local user groups with localized
security policies. Local user groups can contain nested groups and user groups that are imported from Active
Directory. The ASA consolidates local and Active Directory groups.
A user can belong to local user groups and user groups imported from Active Directory.
Because you can use usernames and user group names directly in an ACL, you need to configure local user
groups only if:
• You want to create a group of users defined in the LOCAL database.
• You want to create a group of users or user groups that are not captured in a single user group defined
on the AD server.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Local User Groups.
• Choose Add to add a new object. Enter a name and optionally, a description.
Step 3 Add users or groups to the object using any of these methods:
• Select existing users or groups—Select the domain that contains the user or group, then pick the user
or group name from the lists and click Add. For long lists, use the Find box to help locate the user. The
names are pulled from the server for the selected domain.
• Manually type user names—You can simply type in the user or group names in the bottom edit box
and click Add. When using this method, the selected domain name is ignored, and the default domain
is used if you do not specify one. For users, the format is domain_name\username; for groups, there is
a double \\, domain_name\\group_name.
33
Configure Objects
You can now use this user object group when you create a rule. For an edited object group, the change is
Configure Security Group Object Groups

You can create security group object groups for use in features that support Cisco TrustSec by including the
group in an extended ACL, which in turn can be used in an access rule, for example.
When integrated with Cisco TrustSec, the ASA downloads security group information from the ISE. The ISE
acts as an identity repository, by providing Cisco TrustSec tag-to-user identity mapping and Cisco TrustSec
tag-to-server resource mapping. You provision and manage security group ACLs centrally on the ISE.
However, the ASA might have localized network resources that are not defined globally that require local
security groups with localized security policies. Local security groups can contain nested security groups that
are downloaded from the ISE. The ASA consolidates local and central security groups.
To create local security groups on the ASA, you create a local security object group. A local security object
group can contain one or more nested security object groups or Security IDs or security group names. You
can also create a new Security ID or security group name that does not exist on the ASA.
You can use the security object groups you create on the ASA to control access to network resources. You
can use the security object group as part of an access group or service policy.
Tip If you create a group with tags or names that are not known to the ASA, any rules that use the group will
be inactive until the tags or names are resolved with ISE.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Security Group Object Groups.
Step 3 Add security groups to the object using any of these methods:
• Select existing local security group object groups—Pick from the list of objects already defined and
click Add. For long lists, use the Find box to help locate the object.
• Select security groups discovered from ISE—Pick groups from the list of existing groups and click
Add.
• Manually add security tags or names—You can simply type in the tag number or security group name
in the bottom edit box and click Add. A tag is a number from 1 to 65533 and is assigned to a device
through IEEE 802.1X authentication, web authentication, or MAC authentication bypass (MAB) by the
ISE. Security group names are created on the ISE and provide user-friendly names for security groups.
The security group table maps SGTs to security group names. Consult your ISE configuration for the
valid tags and names.
34
Configure Objects
You can now use this security group object group when you create a rule. For an edited object group, the
change is inherited automatically by any rules using the group.
Configure Time Ranges

A time range object defines a specific time consisting of a start time, an end time, and optional recurring
entries. You use these objects on ACL rules to provide time-based access to certain features or assets. For
example, you could create an access rule that allows access to a particular server during working hours only.
Note You can include multiple periodic entries in a time range object. If a time range has both absolute and
periodic values specified, then the periodic values are evaluated only after the absolute start time is reached,
and they are not further evaluated after the absolute end time is reached.
Creating a time range does not restrict access to the device. This procedure defines the time range only. You
must then use the object in an access control rule.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Time Ranges.
• Choose Add to add a new time range. Enter a name and optionally, a description.
• Choose an existing time range and click Edit.
Step 3 Choose the overall start and end time.

The default is to start now and never end, but you can set specific dates and times. The time range is inclusive
of the times that you enter.
Step 4 (Optional) Configure recurring periods within the overall active time, such as the days of the week or the
recurring weekly interval in which the time range will be active.
a) Click Add, or select an existing period and click Edit.
b) Do one of the following:
• Click Specify days of the week and times on which this recurring range will be active, and choose
the days and times from the lists.
• Click Specify a weekly interval when this recurring range will be active, and choose the days
and times from the lists.
c) Click OK.
Step 5 Click OK, and then click Apply.
35
Monitoring Objects
Monitoring Objects
For network, service, and security group objects, you can analyze the usage of an individual object. From
their page in the Configuration > Firewall > Objects folder, click the Where Used button.
For network objects, you can also click the Not Used button to find objects that are not used in any rules or
other objects. This display gives you a short-cut for deleting these unused objects.
History for Objects

Platform
Feature Name Releases Description
Object groups 7.0(1) Object groups simplify ACL creation and maintenance.
Regular expressions and policy maps 7.2(1) Regular expressions and policy maps were introduced to be used under
inspection policy maps. The following commands were introduced:
class-map type regex, regex, match regex.
Objects 8.3(1) Object support was introduced.
User Object Groups for Identity 8.4(2) User object groups for identity firewall were introduced.
Firewall
Security Group Object Groups for Cisco 8.4(2) Security group object groups for Cisco TrustSec were introduced.
TrustSec
Mixed IPv4 and IPv6 network object 9.0(1) Previously, network object groups could only contain all IPv4 addresses
groups or all IPv6 addresses. Now network object groups can support a mix
of both IPv4 and IPv6 addresses.
Note You cannot use a mixed object group for
NAT.
Configuration > Firewall > Objects > Service Objects/Groups,
Service object support for Stream 9.5(2) You can now create service objects and groups that specific SCTP
Control Transmission Protocol (SCTP) ports.
We modified the add/edit dialog boxes for service objects and groups
on the Configuration > Firewall > Objects > Service
Objects/Groups page.
36
CHAPTER 4
Access Control Lists
Access control lists (ACLs) are used by many different features. When applied to interfaces or globally as
access rules, they permit or deny traffic that flows through the appliance. For other features, the ACL selects
the traffic to which the feature will apply, performing a matching service rather than a control service.
The following sections explain the basics of ACLs and how to configure and monitor them. Access rules,
ACLs applied globally or to interfaces, are explained in more detail in Access Rules, on page 11.
• About ACLs, page 37

• Guidelines for ACLs, page 41
• Configure ACLs, page 42
• Monitoring ACLs, page 51
• History for ACLs, page 51
About ACLs
Access control lists (ACLs) identify traffic flows by one or more characteristics, including source and destination
IP address, IP protocol, ports, EtherType, and other parameters, depending on the type of ACL. ACLs are
used in a variety of features. ACLs are made up of one or more access control entries (ACEs).
ACL Types
The ASA uses the following types of ACLs:
• Extended ACLs—Extended ACLs are the main type that you will use. These ACLs are used for access
rules to permit and deny traffic through the device, and for traffic matching by many features, including
service policies, AAA rules, WCCP, Botnet Traffic Filter, and VPN group and DAP policies. In ASDM,
many of these features have their own rules pages and they cannot use extended ACLs that you define
in the ACL Manager, although ACL Manager will display the ACLs created on those pages. See Configure
Extended ACLs, on page 42.
• EtherType ACLs—EtherType ACLs apply to non-IP layer-2 traffic in transparent firewall mode. You
can use these rules to permit or drop traffic based on the EtherType value in the layer-2 packet. With
37
About ACLs
EtherType ACLs, you can control the flow of non-IP traffic across the device. See Configure EtherType
Rules (Transparent Mode Only), on page 24.
• Webtype ACLs—Webtype ACLs are used for filtering clientless SSL VPN traffic. These ACLs can
deny access based on URLs or destination addresses. See Configure Webtype ACLs, on page 48.
• Standard ACLs—Standard ACLs identify traffic by destination address only. There are few features
that use them: route maps and VPN filters. Because VPN filters also allow extended access lists, limit
standard ACL use to route maps. See Configure Standard ACLs, on page 47.
The following table lists some common uses for ACLs and the type to use.
Table 2: ACL Types and Common Uses
ACL Use ACL Type Description

Control network access for IP traffic (routed Extended The ASA does not allow any traffic from a lower security
and transparent mode) interface to a higher security interface unless it is explicitly
permitted by an extended ACL.
Note To access the ASA interface for management access,
you do not also need an ACL allowing the host IP
address. You only need to configure management
access according to the general operations
configuration guide.
Identify traffic for AAA rules Extended AAA rules use ACLs to identify traffic.
Augment network access control for IP Extended, downloaded You can configure the RADIUS server to download a dynamic
traffic for a given user from a AAA server per ACL to be applied to the user, or the server can send the name
user of an ACL that you already configured on the ASA.
VPN access and filtering Extended Group policies for remote access and site to site VPNs use
standard or extended ACLs for filtering. Remote access VPNs
Standard
also use extended ACLs for client firewall configurations and
dynamic access policies.
Identify traffic in a traffic class map for Extended ACLs can be used to identify traffic in a class map, which is
Modular Policy Framework used for features that support Modular Policy Framework.
Features that support Modular Policy Framework include
TCP and general connection settings, and inspection.
For transparent firewall mode, control EtherType You can configure an ACL that controls traffic based on its
network access for non-IP traffic EtherType.
Identify route filtering and redistribution Standard Various routing protocols use standard ACLs for route
filtering and redistribution (through route maps) for IPv4
Extended
addresses, and extended ACLs for IPv6.
Filtering for clientless SSL VPN Webtype You can configure a webtype ACL to filter URLs and
destinations.
38
About ACLs
The ACL Manager

The ACL Manager appears in two forms:
• In the main window, for example, by selecting Configuration > Firewall > Advanced > ACL Manager.
In this case, the ACL Manager shows extended ACLs only. These ACLs include those generated by
rules you create in the Access Rules, Service Policy Rules, and AAA Rules pages. Be careful that edits
you make in ACL Manager do not negatively impact these rules; changes you make here will be reflected
on those other pages.
• From a policy that requires an ACL, by clicking the Manage button next to the field. In this case, the
ACL Manager can have separate tabs for standard and extended ACLs, if the policy allows either type.
Otherwise, the view is filtered to show standard, extended, or webtype ACLs only. The ACL Manager
never shows EtherType ACLs.
There are separate pages for standard ACLs and webtype ACLs, so that you can configure them in the main
window. These pages are functionally equivalent to the ACL Manager without the name:
• Standard ACLs—Configuration > Firewall > Advanced > Standard ACL.
• Webtype ACLs—Configuration > Remote Access VPN > Clientless SSL VPN Access > Advanced
> Web ACLs.
ACL Names
Each ACL has a name or numeric ID, such as outside_in, OUTSIDE_IN, or 101. Limit the names to 241
characters or fewer.Consider using all uppercase letters to make it easier to find the name when viewing a
running configuration.
Develop a naming convention that will help you identify the intended purpose of the ACL. For example,
ASDM uses the convention interface-name_purpose_direction, such as “outside_access_in”, for an ACL
applied to the “outside” interface in the inbound direction.
Traditionally, ACL IDs were numbers. Standard ACLs were in the range 1-99 or 1300-1999. Extended ACLs
were in the range 100-199 or 2000-2699. The ASA does not enforce these ranges, but if you want to use
numbers, you might want to stick to these conventions to maintain consistency with routers running IOS
Software.
Access Control Entry Order

An ACL is made up of one or more ACEs. Unless you explicitly insert an ACE at a given line, each ACE
that you enter for a given ACL name is appended to the end of the ACL.
The order of ACEs is important. When the ASA decides whether to forward or drop a packet, the ASA tests
the packet against each ACE in the order in which the entries are listed. After a match is found, no more ACEs
are checked.
Thus, if you place a more specific rule after a more general rule, the more specific rule might never be hit.
For example, if you want to permit network 10.1.1.0/24, but drop traffic from host 10.1.1.15 on that subnet,
the ACE that denies 10.1.1.15 must come before the one that permits 10.1.1.0/24. If the permit 10.1.1.0/24
ACE comes first, 10.1.1.15 will be allowed, and the deny ACE will never be matched.
Use the Up and Down buttons to reposition rules as necessary.
39
About ACLs
Permit/Deny vs. Match/Do Not Match

Access control entries either “permit” or “deny” traffic that matches the rule. When you apply an ACL to a
feature that determines whether traffic is allowed through the ASA or is dropped, such as global and interface
access rules, “permit” and “deny” mean what they say.
For other features, such as service policy rules, “permit” and “deny” actually mean “match” or “do not match.”
In these cases, the ACL is selecting the traffic that should receive the services of that feature, such as application
inspection or redirection to a service module. “Denied” traffic is simply traffic that does not match the ACL,
and thus will not receive the service. (In ASDM, service policy rules actually use Match/Do Not Match, and
AAA rules use Authenticate/Do Not Authenticate, for example, but in the CLI, it is always permit/deny.)
Access Control Implicit Deny

All ACLs have an implicit deny statement at the end. Thus, for traffic controlling ACLs such as those applied
to interfaces, if you do not explicitly permit a type of traffic, that traffic is dropped. For example, if you want
to allow all users to access a network through the ASA except for one or more particular addresses, then you
need to deny those particular addresses and then permit all others.
For ACLs used to select traffic for a service, you must explicitly “permit” the traffic; any traffic not “permitted”
will not be matched for the service; “denied” traffic bypasses the service.
For EtherType ACLs, the implicit deny at the end of the ACL does not affect IP traffic or ARPs; for example,
if you allow EtherType 8037, the implicit deny at the end of the ACL does not now block any IP traffic that
you previously allowed with an extended ACL (or implicitly allowed from a high security interface to a low
security interface). However, if you explicitly deny all traffic with an EtherType ACE, then IP and ARP traffic
is denied; only physical protocol traffic, such as auto-negotiation, is still allowed.
IP Addresses Used for Extended ACLs When You Use NAT

When you use NAT or PAT, you are translating addresses or ports, typically mapping between internal and
external addresses. If you need to create an extended ACL that applies to addresses or ports that have been
translated, you need to determine whether to use the real (untranslated) addresses or ports or the mapped ones.
The requirement differs by feature.
Using the real address and port means that if the NAT configuration changes, you do not need to change the
ACLs.
Features That Use Real IP Addresses

The following commands and features use real IP addresses in the ACLs, even if the address as seen on an
interface is the mapped address:
• Access Rules (extended ACLs referenced by the access-group command)
• Service Policy Rules (Modular Policy Framework match access-list command)
• Botnet Traffic Filter traffic classification (dynamic-filter enable classify-list command)
• AAA Rules (aaa ... match commands)
• WCCP (wccp redirect-list group-list command)
40
Guidelines for ACLs
For example, if you configure NAT for an inside server, 10.1.1.5, so that it has a publicly routable IP address
on the outside, 209.165.201.5, then the access rule to allow the outside traffic to access the inside server needs
to reference the server’s real IP address (10.1.1.5), and not the mapped address (209.165.201.5).
Features That Use Mapped IP Addresses

The following features use ACLs, but these ACLs use the mapped values as seen on an interface:
• IPsec ACLs
• capture command ACLs
• Per-user ACLs
• Routing protocol ACLs
• All other feature ACLs.
Time-Based ACEs
You can apply time range objects to extended and webtype ACEs so that the rules are active for specific time
periods only. These types of rules let you differentiate between activity that is acceptable at certain times of
the day but that is unacceptable at other times. For example, you could provide additional restrictions during
working hours, and relax them after work hours or at lunch. Conversely, you could essentially shut your
network down during non-work hours.
Note Users could experience a delay of approximately 80 to 100 seconds after the specified end time for the
ACL to become inactive. For example, if the specified end time is 3:50, because the end time is inclusive,
the command is picked up anywhere between 3:51:00 and 3:51:59. After the command is picked up, the
ASA finishes any currently running task and then services the command to deactivate the ACL.
Guidelines for ACLs

Firewall Mode
• Extended and standard ACLs are supported in routed and transparent firewall modes.
• Webtype ACLs are supported in routed mode only.
• EtherType ACLs are supported in transparent mode only.
Failover and Clustering

Configuration sessions are not synchronized across failover or clustered units. When you commit the changes
in a session, they are made in all failover and cluster units as normal.
IPv6
• Extended and webtype ACLs allow a mix of IPv4 and IPv6 addresses.
41
Configure ACLs
• Standard ACLs do not allow IPv6 addresses.

• EtherType ACLs do not contain IP addresses.
Additional Guidelines
• When you specify a network mask, the method is different from the Cisco IOS software access-list
command. The ASA uses a network mask (for example, 255.255.255.0 for a Class C mask). The Cisco
IOS mask uses wildcard bits (for example, 0.0.0.255).
• Normally, you cannot reference an object or object group that does not exist in an ACL or object group,
or delete one that is currently referenced. You also cannot reference an ACL that does not exist in an
access-group command (to apply access rules). However, you can change this default behavior so that
you can “forward reference” objects or ACLs before you create them. Until you create the objects or
ACLs, any rules or access groups that reference them are ignored. To enable forward referencing, select
the option in the access rules advanced settings; choose Configuration > Access Rules and click the
Advanced button.
• If you enter more than one item in source or destination address, or source or destination service, ASDM
automatically creates an object group for them with the prefix DM_INLINE. These objects are
automatically expanded to their component parts in the rule table view, but you can see the object names
if you deselect the Auto-expand network and service objects with specified prefix rule table preference
in Tools > Preferences.
• (Extended ACL only) The following features use ACLs, but cannot accept an ACL with identity firewall
(specifying user or group names), FQDN (fully-qualified domain names), or Cisco TrustSec values:
◦VPN crypto map command
◦VPN group-policy command, except for vpn-filter
◦WCCP
◦DAP
Configure ACLs
The following sections explain how to configure the various types of generic ACL, except those used as access
rules (including EtherType), service policy rules, AAA rules, and other uses where ASDM provides a
special-purpose page for those rule-based policies.
Configure Extended ACLs

An extended ACL is represented as a named container of ACEs. To create a new ACL, you must first create
the container. Then, you can add ACEs, edit existing ACEs, and reorder the ACEs using the table in ACL
Manager.
The extended ACL can include a mix of IPv4 and IPv6 addresses.
42
Configure ACLs
Procedure
Step 1 Choose Configuration > Firewall > Advanced > ACL Manager.
Step 2 If you are creating a new ACL, choose Add > Add ACL, fill in a name, and click OK.
The ACL container is added to the table. You can later rename it by selecting it and clicking Edit.

• To add an ACE at the end of the ACL, select the ACL name or any ACE within it and choose Add >
Add ACE.
• To insert an ACE at a specific location, select an existing ACE and choose Add > Insert to add the
ACE above the rule, or choose Add > Insert After.
Step 4 Fill in the ACE properties. The primary options to select are:
• Action: Permit/Deny—Whether you are permitting (selecting) the described traffic or are denying
(deselecting, not matching) it.
you want to focus the rule more narrowly than all IP traffic. If you implement Cisco TrustSec, you can
use security groups to define source and destination.
For detailed information on all of the available options, see Extended ACE Properties, on page 43.
When you are finished defining the ACE, click OK to add the rule to the table.
Step 5 Click Apply.
Extended ACE Properties

When you add or edit an ACE in an extended ACL, you can configure the following properties. In many
fields, you can click the “...” button on the right of the edit box to select, create, or edit objects that are available
for the field.
Action: Permit/Deny
Whether you are permitting (selecting) the described traffic or are denying (deselecting, not matching)
it.
43
Configure ACLs
Source Criteria
The characteristics of the originator of the traffic you are trying to match. You must configure Source,
Source
The IPv4 or IPv6 address of the source. The default is any, which matches all IPv4 or IPv6
User
If you enable the identity firewall, you can specify a user or user group as the traffic source. The
IP address the user is currently using will match the rule. You can specify a username
(DOMAIN\user), a user group (DOMAIN\\group, note the double \ indicates a group name), or
a user object group. For this field, it is far easier to click “...” to select names from your AAA
server group than to type them in.
Security Group
If you enable Cisco TrustSec, you can specify a security group name or tag (1-65533), or security
group object.
More Options > Source Service

If you specify TCP, UDP, or SCTP as the destination service, you can optionally specify a
predefined service object for TCP, UDP, TCP-UDP, or SCTP, or use your own object. Typically,
you define the destination service only and not the source service. Note that if you define the
source service, the destination service protocol must match it (for example, both TCP, with or
without port definitions).
44
Configure ACLs
Destination Criteria
The characteristics of the target of the traffic you are trying to match. You must configure Destination,
Destination
The IPv4 or IPv6 address of the destination. The default is any, which matches all IPv4 or IPv6
Security Group
If you enable Cisco TrustSec, you can specify a security group name or tag (1-65533), or security
group object.
Service
The protocol of the traffic, such as IP, TCP, UDP, and optionally ports for TCP, UDP, or SCTP.
The default is IP, but you can select a more specific protocol to target traffic with more granularity.
Typically, you would select some type of service object. For TCP, UDP, and SCTP, you can
specify ports, for example, tcp/80, tcp/http, tcp/10-20 (for a range of ports), tcp-udp/80 (match
any TCP or UDP traffic on port 80), sctp/diameter, and so forth. For detailed information on
specifying services, see Service Specifications in Extended ACEs, on page 46.
Description
A explanation of the purpose of the ACE, up to 100 characters per line. You can enter multiple lines;
each line is added as a remark in the CLI, and the remarks are placed before the ACE.
Note If you add remarks with non-English characters on one platform (such as
Windows) then try to remove them from another platform (such as Linux), you
might not be able to edit or delete them because the original characters might
not be correctly recognized. This limitation is due to an underlying platform
dependency that encodes different language characters in different ways.
45
Configure ACLs
Enable Logging; Logging Level; More Options > Logging Interval

The logging options define how syslog messages will be generated for rules. These options apply to
ACLs that are used as access rules only, that is, those attached to interfaces or applied globally. The
options are ignored for ACLs used for other features. You can implement the following logging options:
Deselect Enable Logging
This will disable logging for the rule. No syslog messages of any type will be issued for
connections that match this rule.
Select Enable Logging with Logging Level = Default

This provides the default logging for rules. Syslog message 106023 is issued for each denied
connection. If the appliance comes under attack, the frequency of issuing this message could
impact services.
Select Enable Logging with Non-Default Logging Level

This provides a summarized syslog message, 106100, instead of 106023. Message 106100 is
issued upon first hit, then again at each interval configured in More Options > Logging Interval
(default is every 300 seconds, you can specify 1-600), showing the number of hits during that
interval. The recommended logging level is Informational.
Summarizing deny messages can reduce the impact of attacks and possibly make it easier for
you to analyze messages. If you do come under a denial of service attack, you might see message
106101, which indicates that the number of cached deny flows used to produce the hit count for
message 106100 has exceeded the maximum for an interval. At this point, the appliance stops
collecting statistics until the next interval to mitigate the attack.
More Options > Enable Rule

Whether the rule is active on the device. Disabled rules appear with strike-through text in the rule table.
Disabling a rule lets you stop its application to traffic without deleting it, so you can enable it again
later if you decide you need it.
More Options > Time Range

The name of the time range object that defines the times of day and days of the week when the rule
should be active. If you do not specify a time range, the rule is always active.
Service Specifications in Extended ACEs

For the destination service in an extended ACE, you can specify any of the following criteria. The options
are similar, but more limited, for source service, which is limited to TCP, UDP, TCP-UDP, or SCTP criteria.
Object name
The name of any type of service object or service object group. These objects can include many of the
specifications explained below, allowing you to easily reuse service definitions among ACLs. There
are many pre-defined objects, so you might find what you need without having to manually type the
specification or create your own objects.
46
Configure ACLs
Protocol
A number between 1-255, or a well-known name, such as ip, tcp, udp, gre, and so forth.
TCP, UDP, TCP-UDP, SCTP ports

You can include port specifications on the tcp, udp, tcp-udp, and sctp keywords. The tcp-udp keyword
lets you define ports for both protocols without having to specify them separately. You can use the
following methods to specify ports:
• Single port—tcp/80, udp/80, tcp-udp/80, sctp/3868, or a well-known service name, such as
tcp/www, udp/snmp, or sctp/diameter.
• Range of ports—tcp/1-100, udp/1-100, tcp-udp/1-100, sctp/1-100 matches ports 1-100 inclusive.
• Not equal to a port—Add != to the beginning of the specification, for example, !=tcp/80 to match
any TCP traffic except TCP port 80 (HTTP).
• Less than a port number—Add <, for example <tcp/150 to match TCP traffic for any port below
150.
• Greater than a port number—Add >, for example, >tcp150 to match TCP traffic for any port above
150.
Note DNS, Discard, Echo, Ident, NTP, RPC, SUNRPC, and Talk each require one
definition for TCP and one for UDP. TACACS+ requires one definition for
port 49 on TCP.
ICMP, ICMP6 messages

You can target specific messages (such as ping echo request and reply messages) and even message
codes. There are many pre-defined objects that cover ICMP (for IPv4) and ICMP6 (for IPv6), so you
might not need to manually define the criteria. The format is:
icmp/icmp_message_type[/icmp_message_code]
icmp6/icmp6_message_type[/icmp6_message_code]
Where the message type is 1-255 or a well-known name, and the code is 0-255. Ensure that the number
you select matches to an actual type/code or the ACE will never be matched.
Configure Standard ACLs

A standard ACL is represented as a named container of ACEs. To create a new ACL, you must first create
the container. Then, you can add ACEs, edit existing ACEs, and reorder the ACEs using the standard ACL
table. The table can appear as a tab in the ACL Manager when you configure ACLs while configuring the
policies that use them, in which case the procedures are the same except for how you get to the window.
A standard ACL uses IPv4 addresses only, and defines destination addresses only.
47
Configure ACLs
Procedure
Step 1 Choose Configuration > Firewall > Advanced > Standard ACL.
The ACL container is added to the table. You cannot rename a standard ACL.

Add ACE.
Step 4 Fill in the ACE properties. The options are:

• Address—A definition of the destination or target address of the traffic flow. You can specify a host
address such as 10.100.1.1, a network (in 10.100.1.0/24 or 10.100.1.0/255.255.255.0 format), or you
can select a network object (which simply loads the contents of the object into the Address field).
• Description—A explanation of the purpose of the ACE, up to 100 characters per line. You can enter
multiple lines; each line is added as a remark in the CLI, and the remarks are placed before the ACE.
Note If you add remarks with non-English characters on one platform (such as Windows) then try
to remove them from another platform (such as Linux), you might not be able to edit or delete
them because the original characters might not be correctly recognized. This limitation is due
to an underlying platform dependency that encodes different language characters in different
ways.
Step 5 Click Apply.
Configure Webtype ACLs

Webtype ACLs are used for filtering clientless SSL VPN traffic, constraining user access to specific networks,
subnets, hosts, and Web servers. If you do not define a filter, all connections are allowed. A webtype ACL is
represented as a named container of ACEs. To create a new ACL, you must first create the container. Then,
you can add ACEs, edit existing ACEs, and reorder the ACEs using the Web ACL table. The table appears
as the ACL Manager when you configure webtype ACLs while configuring the policies that use them, in
which case the procedures are the same except for how you get to the window.
The webtype ACL can include a mix of IPv4 and IPv6 addresses in addition to URL specifications.
48
Configure ACLs
Procedure
Step 1 Choose Configuration > Remote Access VPN > Clientless SSL VPN Access > Advanced > Web >
ACLs.
The ACL container is added to the table. You can later rename it by selecting it and clicking Edit.

Add ACE.
Step 4 Fill in the ACE properties. The primary options to select are:
• Filter—The traffic matching criteria, based on the destination. You can either specify a URL by selecting
the protocol and entering the server name and optionally, path and file name, or you can specify a
destination IPv4 or IPv6 address and TCP service.
For detailed information on all of the available options, see Webtype ACE Properties, on page 49.
Step 5 Click Apply.
Webtype ACE Properties

When you add or edit an ACE in a webtype ACL, you can configure the following properties. In many fields,
you can click the “...” button on the right of the edit box to select, create, or edit objects that are available for
the field.
For a given ACE, you can filter on URL or Address, but not both.
◦Filter on URL—Match traffic based on destination URL. Select the protocol and enter the server
name and optionally, path and file name. For example, http://www.example.com or to cover all
servers, http://*.example.com. Following are some tips and limitations on specifying URLs:
◦Select any to match all URLs.
◦‘Permit url any' will allow all the URLs that have the format protocol://server-ip/path and
will block traffic that does not match this pattern, such as port-forwarding. There should be
an ACE to allow connections to the required port (port 1494 in the case of Citrix) so that an
implicit deny does not occur.
49
Configure ACLs
◦Smart tunnel and ica plug-ins are not affected by an ACL with ‘permit url any’ because they
match smart-tunnel:// and ica:// types only.
◦You can use these protocols: cifs://, citrix://, citrixs://, ftp://, http://, https://, imap4://, nfs://,
pop3://, smart-tunnel://, and smtp://. You can also use wildcards in the protocol; for example,
htt* matches http and https, and an asterisk * matches all protocols. For example,
*://*.example.com matches any type URL-based traffic to the example.com network.
◦If you specify a smart-tunnel:// URL, you can include the server name only. The URL cannot
contain a path. For example, smart-tunnel://www.example.com is acceptable, but
smart-tunnel://www.example.com/index.html is not.
◦An asterisk * matches none or any number of characters. To match any http URL, enter
http://*/*.
◦A question mark ? matches any one character exactly.
◦Square brackets [] are range operators, matching any character in the range. For example, to
match both http://www.cisco.com:80/ and http://www.cisco.com:81/, enter
http://www.cisco.com:8[01]/.
• Filter on Address and Service—Match traffic based on destination address and service.
◦Address—The IPv4 or IPv6 address of the destination. To match all addresses, you can use any,
which matches all IPv4 or IPv6 addresses, any4 to match IPv4 only, or any6 to match IPv6 only.
You can specify a single host address (such as 10.100.10.5 or 2001:DB8::0DB8:800:200C:417A),
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), or select a network object, which fills in the field with the contents of
the object.
◦Service—A single TCP service specification. The default is tcp with no ports, but you can specify
a single port (such as tcp/80 or tcp/www) or port range (such as tcp/1-100). You can include
operators; for example, !=tcp/80 excludes port 80; <tcp/80 is all ports less than 80; >tcp/80 is all
ports greater than 80.
• Enable Logging; Logging Level; More Options > Logging Interval—The logging options define
how syslog messages will be generated for rules that actually deny traffic. You can implement the
following logging options:
◦Deselect Enable Logging—This will disable logging for the rule. No syslog messages of any type
will be issued for traffic denied by this rule.
◦Select Enable Logging with Logging Level = Default—This provides the default logging for
rules. Syslog message 106103 is issued for each denied packet. If the appliance comes under attack,
the frequency of issuing this message could impact services.
◦Select Enable Logging with Non-Default Logging Level—This provides a summarized syslog
message, 106102, instead of 106103. Message 106102 is issued upon first hit, then again at each
interval configured in More Options > Logging Interval (default is every 300 seconds, you can
specify 1-600), showing the number of hits during that interval. The recommended logging level
is Informational.
• More Options > Time Range—The name of the time range object that defines the times of day and
days of the week when the rule should be active. If you do not specify a time range, the rule is always
active.
50
Monitoring ACLs
Examples for Webtype ACLs

Following are some examples of URL-based rules for webtype ACLs.
Filter Effect
Deny url http://*.yahoo.com/ Denies access to all of Yahoo!
Deny url cifs://fileserver/share/directory Denies access to all files in the specified

location.
Deny url https://www.example.com/ directory/file.html Denies access to the specified file.
Permit url https://www.example.com/directory Permits access to the specified location.
Deny url http://*:8080/ Denies HTTPS access to anywhere via port

8080.
Deny url http://10.10.10.10 Denies HTTP access to 10.10.10.10.
Permit url any Permits access to any URL. Usually used

after an ACL that denies url access.
Monitoring ACLs
The ACL Manager, Standard ACL, Web ACL, and EtherType ACL tables show a consolidated view of ACLs.
But to see exactly what is configured on the device, you can use the following commands. Choose Tools >
Command Line Interface to enter the commands.
• show access-list [name]—Displays the access lists, including the line number for each ACE and hit
counts. Include an ACL name or you will see all access lists.
• show running-config access-list [name]—Displays the current running access-list configuration. Include
an ACL name or you will see all access lists.
History for ACLs

Extended, standard, webtype ACLs 7.0(1) ACLs are used to control network access or to specify traffic for many
features to act upon. An extended access control list is used for
through-the-box access control and several other features. Standard
ACLs are used in route maps and VPN filters. Webtype ACLs are used
in clientless SSL VPN filtering. EtherType ACLs control non-IP layer
2 traffic.
We added the ACL Manager and other pages for configuring ACLs.
51
History for ACLs

Real IP addresses in extended ACLs 8.3(1) When using NAT or PAT, mapped addresses and ports are no longer
used in an ACL for several features. You must use the real, untranslated
addresses and ports for these features. Using the real address and port
means that if the NAT configuration changes, you do not need to
change the ACLs.
Support for Identity Firewall in 8.4(2) You can now use identity firewall users and groups for the source and
extended ACLs destination. You can use an identity firewall ACL with access rules,
AAA rules, and for VPN authentication.
EtherType ACL support for IS-IS traffic 8.4(5), 9.1(2) In transparent firewall mode, the ASA can now control IS-IS traffic
using an EtherType ACL.
We modified the following screen: Configuration > Device
Management > Management Access > EtherType Rules.
Support for Cisco TrustSec in extended 9.0(1) You can now use Cisco TrustSec security groups for the source and
ACLs destination. You can use an identity firewall ACL with access rules.
Unified extended and webtype ACLs 9.0(1) Extended and webtype ACLs now support IPv4 and IPv6 addresses.
for IPv4 and IPv6 You can even specify a mix of IPv4 and IPv6 addresses for the source
and destination. The any keyword was changed to represent IPv4 and
IPv6 traffic. The any4 and any6 keywords were added to represent
IPv4-only and IPv6-only traffic, respectively. The IPv6-specific ACLs
are deprecated. Existing IPv6 ACLs are migrated to extended ACLs.
See the release notes for more information about migration.
Configuration > Firewall > Access Rules
Configuration > Remote Access VPN > Network (Client) Access >
Group Policies > General > More Options
Configuration > Firewall > Objects > Service Objects/Groups
Configuration session for editing ACLs 9.3(2) You can now edit ACLs and objects in an isolated configuration
and objects. session. You can also forward reference objects and ACLs, that is,
configure rules and access groups for objects or ACLs that do not yet
Forward referencing of objects and
exist.
ACLs in access rules.
We modified the Advanced settings for access rules.
ACL support for Stream Control 9.5(2) You can now create ACL rules using the sctp protocol, including port
Transmission Protocol (SCTP) specifications.
We modified the add/edit dialog boxes for access control entries on
the Configuration > Firewall > Advanced > ACL Manager page.
52
History for ACLs
53
History for ACLs
54
CHAPTER 5
Identity Firewall
This chapter describes how to configure the ASA for the Identity Firewall.
• About the Identity Firewall, page 55

• Guidelines for the Identity Firewall, page 61
• Prerequisites for the Identity Firewall, page 63
• Configure the Identity Firewall, page 64
• Monitoring the Identity Firewall, page 70
• History for the Identity Firewall, page 70
About the Identity Firewall

In an enterprise, users often need access to one or more server resources. Typically, a firewall is not aware of
the users’ identities and, therefore, cannot apply security policies based on identity. To configure per-user
access policies, you must configure a user authentication proxy, which requires user interaction (a
username/password query).
The Identity Firewall in the ASA provides more granular access control based on users’ identities. You can
configure access rules and security policies based on user names and user group names rather than through
source IP addresses. The ASA applies the security policies based on an association of IP addresses to Windows
Active Directory login information and reports events based on the mapped usernames instead of network IP
addresses.
The Identity Firewall integrates with Microsoft Active Directory in conjunction with an external Active
Directory (AD) Agent that provides the actual identity mapping. The ASA uses Windows Active Directory
as the source to retrieve the current user identity information for specific IP addresses and allows transparent
authentication for Active Directory users.
Identity-based firewall services enhance the existing access control and security policy mechanisms by allowing
users or groups to be specified in place of source IP addresses. Identity-based security policies can be interleaved
without restriction between traditional IP address-based rules.
The key benefits of the Identity Firewall include:
• Decoupling network topology from security policies
55
• Simplifying the creation of security policies

• Providing the ability to easily identify user activities on network resources
• Simplifying user activity monitoring
Architecture for Identity Firewall Deployments

The Identity Firewall integrates with Window Active Directory in conjunction with an external Active Directory
(AD) Agent that provides the actual identity mapping.
The identity firewall consists of three components:
• ASA
• Microsoft Active Directory
Although Active Directory is part of the Identity Firewall on the ASA, Active Directory administrators
manage it. The reliability and accuracy of the data depends on data in Active Directory.
Supported versions include Windows Server 2003, Windows Server 2008, and Windows Server 2008
R2 servers.
• Active Directory (AD) Agent
The AD Agent runs on a Windows server. Supported Windows servers include Windows 2003, Windows
2008, and Windows 2008 R2.
Note Windows 2003 R2 is not supported for the AD Agent server.
The following figure show the components of the Identity Firewall. The succeeding table describes the roles
of these components and how they communicate with one another.
Figure 3: Identity Firewall Components
56
1 On the ASA: Administrators configure local user 4 Client <-> ASA: The client logs into the network
groups and Identity Firewall policies. through Microsoft Active Directory. The AD
Server authenticates users and generates user
login security logs.
Alternatively, the client can log into the network
through a cut-through proxy or VPN.
2 ASA <-> AD Server: The ASA sends an LDAP 5 ASA <-> Client: Based on the policies
query for the Active Directory groups configured configured on the ASA, it grants or denies access
on the AD Server. to the client.
The ASA consolidates local and Active Directory If configured, the ASA probes the NetBIOS of
groups and applies access rules and Modular the client to pass inactive and no-response users.
Policy Framework security policies based on user
identity.
3 ASA <-> AD Agent: Depending on the Identity 6 AD Agent <-> AD Server: The AD Agent
Firewall configuration, the ASA downloads the maintains a cache of user ID and IP address
IP-user database or sends a RADIUS request to mapped entries. and notifies the ASA of changes.
the AD Agent that asks for the user’s IP address. The AD Agent sends logs to a syslog server.
The ASA forwards the new mapped entries that
have been learned from web authentication and
VPN sessions to the AD Agent.
Features of the Identity Firewall

The Identity Firewall includes the following key features.
Flexibility
• The ASA can retrieve user identity and IP address mapping from the AD Agent by querying the AD
Agent for each new IP address or by maintaining a local copy of the entire user identity and IP address
database.
• Supports host group, subnet, or IP address for the destination of a user identity policy.
• Supports a fully qualified domain name (FQDN) for the source and destination of a user identity policy.
• Supports the combination of 5-tuple policies with ID-based policies. The identity-based feature works
in tandem with the existing 5-tuple solution.
• Supports use with IPS and Application Inspection policies.
• Retrieves user identity information from remote access VPN, AnyConnect VPN, L2TP VPN and
cut-through proxy. All retrieved users are populated to all ASAs that are connected to the AD Agent.
Scalability
• Each AD Agent supports 100 ASAs. Multiple ASAs are able to communicate with a single AD Agent
to provide scalability in larger network deployments.
57
• Supports 30 Active Directory servers provided the IP address is unique among all domains.
• Each user identity in a domain can have up to 8 IP addresses.
• Supports up to 64,000 user identity-IP address mapped entries in active policies for the ASA 5500 Series
models. This limit controls the maximum number of users who have policies applied. The total number
of users are the aggregate of all users configured in all different contexts.
• Supports up to 512 user groups in active ASA policies.
• A single access rule can contain one or more user groups or users.
• Supports multiple domains.
Availability
• The ASA retrieves group information from the Active Directory and falls back to web authentication
for IP addresses when the AD Agent cannot map a source IP address to a user identity.
• The AD Agent continues to function when any of the Active Directory servers or the ASA are not
responding.
• Supports configuring a primary AD Agent and a secondary AD Agent on the ASA. If the primary AD
Agent stops responding, the ASA can switch to the secondary AD Agent.
• If the AD Agent is unavailable, the ASA can fall back to existing identity sources such as cut-through
proxy and VPN authentication.
• The AD Agent runs a watchdog process that automatically restarts its services when they are down.
• Allows a distributed IP address/user mapping database for use among ASAs.
Deployment Scenarios
You can deploy the components of the Identity Firewall in the following ways, depending on your environmental
requirements.
The following figure shows how you can deploy the components of the Identity Firewall to allow for
redundancy. Scenario 1 shows a simple installation without component redundancy. Scenario 2 also shows a
58
simple installation without redundancy. However, in this deployment scenario, the Active Directory server
and AD Agent are co-located on the same Windows server.
Figure 4: Deployment Scenario without Redundancy
The following figure shows how you can deploy the Identity Firewall components to support redundancy.
Scenario 1 shows a deployment with multiple Active Directory servers and a single AD Agent installed on a
separate Windows server. Scenario 2 shows a deployment with multiple Active Directory servers and multiple
AD Agents installed on separate Windows servers.
Figure 5: Deployment Scenario with Redundant Components
59
The following figure shows how all Identity Firewall components—Active Directory server, the AD Agent,
and the clients—are installed and communicate on the LAN.
Figure 6: LAN -based Deployment
The following figure shows a WAN-based deployment to support a remote site. The Active Directory server
and the AD Agent are installed on the main site LAN. The clients are located at a remote site and connect to
the Identity Firewall components over a WAN.
Figure 7: WAN-based Deployment
60
Guidelines for the Identity Firewall
The following figure also shows a WAN-based deployment to support a remote site. The Active Directory
server is installed on the main site LAN. However, the AD Agent is installed and accessed by the clients at
the remote site. The remote clients connect to the Active Directory servers at the main site over a WAN.
Figure 8: WAN-based Deployment with Remote AD Agent
The following figure shows an expanded remote site installation. An AD Agent and Active Directory servers
are installed at the remote site. The clients access these components locally when logging into network resources
located at the main site. The remote Active Directory server must synchronize its data with the central Active
Directory servers located at the main site.
Figure 9: WAN-based Deployment with Remote AD Agent and AD Servers

This section describes the guidelines and limitations that you should check before configuring the Identity
Firewall.
Failover
• The Identity Firewall supports user identity-IP address mapping and AD Agent status replication from
active to standby when Stateful Failover is enabled. However, only user identity-IP address mapping,
61
AD Agent status, and domain status are replicated. User and user group records are not replicated to the
standby ASA.
• When failover is configured, the standby ASA must also be configured to connect to the AD Agent
directly to retrieve user groups. The standby ASA does not send NetBIOS packets to clients even when
the NetBIOS probing options are configured for the Identity Firewall.
• When a client is determined to be inactive by the active ASA, the information is propagated to the
standby ASA. User statistics are not propagated to the standby ASA.
• When you have failover configured, you must configure the AD Agent to communicate with both the
active and standby ASAs. See the Installation and Setup Guide for the Active Directory Agent for the
steps to configure the ASA on the AD Agent server.
IPv6
• The AD Agent supports endpoints with IPv6 addresses. It can receive IPv6 addresses in log events,
maintain them in its cache, and send them through RADIUS messages. The AAA server must use an
IPv4 address.
• NetBIOS over IPv6 is not supported.
• A full URL as a destination address is not supported.
• For NetBIOS probing to function, the network between the ASA, AD Agent, and clients must support
UDP-encapsulated NetBIOS traffic.
• MAC address checking by the Identity Firewall does not work when intervening routers are present.
Users logged into clients that are behind the same router have the same MAC addresses. With this
implementation, all the packets from the same router are able to pass the check, because the ASA is
unable to ascertain the actual MAC addresses behind the router.
• Although you can use user specifications in VPN filter ACLs, the user-based rules are interpreted
uni-directionally rather than bi-directionally, which is how VPN filter usually works. That is, you can
filter based on user-initiated traffic, but the filter does not apply for going from the destination back to
the user. For example, you could include a rule that allows a specific user to ping a server, but that rule
will not allow the server to ping the user.
• The following ASA features do not support using the identity-based object and FQDN in an extended
ACL:
◦Crypto maps
◦WCCP
◦NAT
◦Group policy (except for VPN filters)
◦DAP
• You can use the user-identity update active-user-database command to actively initiate a user-IP
address download from the AD agent.
62
Prerequisites for the Identity Firewall
By design, if a previous download session has finished, the ASA does not allow you to issue this command
again.
As a result, if the user-IP database is very large, the previous download session is not finished yet, and
you issue another user-identity update active-user-database command, the following error message
appears:
“ERROR: one update active-user-database is already in progress.”
You need to wait until the previous session is completely finished, then you can issue another
user-identity update active-user-database command.
Another example of this behavior occurs because of packet loss from the AD Agent to the ASA.
When you issue a user-identity update active-user-database command, the ASA requests the total
number of user-IP mapped entries to be downloaded. Then the AD Agent initiates a UDP connection
to the ASA and sends the change of authorization request packet.
If for some reason the packet is lost, there is no way for the ASA to discern this. As a result, the ASA
holds the session for 4-5 minutes, during which time this error message continues to appear if you have
issued the user-identity update active-user-database command.
• When you use the Cisco Context Directory Agent (CDA) in conjunction with the ASA or Cisco Ironport
Web Security Appliance (WSA), make sure that you open the following ports:
◦Authentication port for UDP—1645
◦Accounting port for UDP—1646
◦Listening port for UDP—3799
The listening port is used to send change of authorization requests from the CDA to the ASA or
to the WSA.
• If the user-identity action domain-controller-down domain_name disable user-identity-rule command

is configured and the specified domain is down, or if the user-identity action ad-agent-down disable
user-identity-rule command is configured and the AD Agent is down, all the logged-in users have the
disabled status.
• For domain names, the following characters are not valid: \/:*?"<>|. For naming conventions, see http:/
/support.microsoft.com/kb/909264.
• For usernames, the following characters are not valid: \/[]:;=,+*?"<>|@.
• For user group names, the following characters are not valid: \/[]:;=,+*?"<>|.
• How you configure the Identity Firewall to retrieve user information from the AD Agent affects the
amount of memory used by the feature. You specify whether the ASA uses on-demand retrieval or full
download retrieval. Choosing on-demand retrieval has the benefit of using less memory, because only
users of received packets are queried and stored.
Prerequisites for the Identity Firewall

This section lists the prerequisites for configuring the Identity Firewall.
63
Configure the Identity Firewall
AD Agent
• The AD Agent must be installed on a Windows server that is accessible to the ASA. Additionally, you
must configure the AD Agent to obtain information from the Active Directory servers and to communicate
with the ASA.
• Supported Windows servers include Windows 2003, Windows 2008, and Windows 2008 R2.
Note Windows 2003 R2 is not supported for the AD Agent server.
• For the steps to install and configure the AD Agent, see the Installation and Setup Guide for the Active
Directory Agent.
• Before configuring the AD Agent in the ASA, obtain the secret key value that the AD Agent and the
ASA use to communicate. This value must match on both the AD Agent and the ASA.
Microsoft Active Directory

• Microsoft Active Directory must be installed on a Windows server and accessible by the ASA. Supported
versions include Windows 2003, 2008, and 2008 R2 servers.
• Before configuring the Active Directory server on the ASA, create a user account in Active Directory
for the ASA.
• Additionally, the ASA sends encrypted log-in information to the Active Directory server by using SSL
enabled over LDAP. SSL must be enabled on the Active Directory server. See the documentation for
Microsoft Active Directory for how to enable SSL for Active Directory.
Note Before running the AD Agent Installer, you must install the patches listed in the README First for the
Cisco Active Directory Agent on each Microsoft Active Directory server that the AD Agent monitors.
These patches are required even when the AD Agent is installed directly on the domain controller server.

To configure the Identity Firewall, perform the following tasks:
Procedure
Step 1 Configure the Active Directory domain in the ASA.

Step 2 Configure the AD Agent in ASA.
Step 3 Configure Identity Options.
Step 4 Configure Identity-based Security Policy. After the AD domain and AD Agent are configured, you can create
identity-based object groups and ACLs for use in many features.
64
Configure the Active Directory Domain

Active Directory domain configuration on the ASA is required for the ASA to download Active Directory
groups and accept user identities from specific domains when receiving IP-user mapping from the AD Agent.
Before You Begin

• Active Directory server IP address
• Distinguished Name for LDAP base DN
• Distinguished Name and password for the Active Directory user that the Identity Firewall uses to connect
to the Active Directory domain controller
To configure the Active Directory domain, perform the following steps:
Procedure
Step 1 Choose Configuration > Firewall > Identity Options.

Step 2 Check the Enable User Identity check box to enable user identity.
Step 3 Click Add.
The Domain dialog box appears.
Step 4 Enter a domain name of up to 32 characters consisting of [a-z], [A-Z], [0-9], [!@#$%^&()-_=+[]{};,. ] except
'.' and ' ' at the first character. If the domain name includes a space, you must enclose that space character in
quotation marks. The domain name is not case sensitive.
When you edit the name of an existing domain, the domain name associated with existing users and user
groups is not changed.
Step 5 Select the Active Directory servers to associate with this domain, or click Manage to add a new server group
to the list.
Step 6 Click OK to save the domain settings and close this dialog box.
Configure Active Directory Server Groups

To configure the Active Directory server group, perform the following steps:
Procedure
Step 1 Choose Configuration > Firewall > Identity Options > Add > Manage.
The Configure Active Directory Server Groups dialog box appears.
Step 2 Click Add.

The Add Active Directory Server Group dialog box appears.
Step 3 To add servers to an Active Directory server group, select the group from the Active Directory Server Groups
list, then click Add.
The Add Active Directory Server dialog box appears.
65
Step 4 Click OK to save the settings and close this dialog box.
Configure Active Directory Agents

Before You Begin
• AD agent IP address
• Shared secret between the ASA and AD agent
To configure the AD Agents, perform the following steps:
Procedure

Step 2 Check the Enable User Identity check box to enable the feature.
Step 3 Click Manage in the Active Directory Agent section.
The Configure Active Directory Agents dialog box appears.
Step 4 Click the Add button.

Step 5 Click OK to save your changes and close this dialog box.
Configure Active Directory Agent Groups

Configure the primary and secondary AD Agents for the AD Agent Server Group. When the ASA detects
that the primary AD Agent is not responding and a secondary agent is specified, the ASA switches to the
secondary AD Agent. The Active Directory server for the AD agent uses RADIUS as the communication
protocol; therefore, you should specify a key attribute for the shared secret between the ASA and AD Agent.
To configure the AD Agent Groups, perform the following steps:
Procedure
Step 1 Click Add from the Configure Active Directory Agents dialog box.
The Add Active Directory Agent Group dialog box appears.
66
Step 2 Enter a name for the AD Agent group.

Step 3 Specify the interface on which the ASA listens for traffic from the AD Agent server, and enter the FQDN of
the server or IP address in the Primary Active Directory Agent section.
Step 4 Enter a timeout interval and the retry interval for the attempts that the ASA will continue to contact the AD
Agent when it is not responding in the Primary Active Directory Agent section.
Step 5 Enter the shared secret key that is used between the primary AD Agent and the ASA.
Step 6 Specify the interface on which the ASA listens for traffic from the AD Agent server, and enter the FQDN of
the server or IP address in the Secondary Active Directory Agent section.
Step 7 Enter a timeout interval and the retry interval for the attempts that the ASA will continue to perform to contact
the AD Agent when it is not responding in the Secondary Active Directory Agent section.
Step 8 Enter the shared secret key that is used between the secondary AD Agent and the ASA.
Step 9 Click OK to save your changes and close this dialog box.
Configure Identity Options

To configure the Identity Options for the Identity Firewall, perform the following steps:
Procedure

Step 2 Check the Enable User Identity check box.
Step 3 To add a domain for the Identity Firewall, click Add to display the Add Domain dialog box.
Step 4 For domains that have already been added to the Domains list, check whether or not to disable rules when the
domain is down because the Active Directory domain controller is not responding.
When a domain is down and this option is checked for that domain, the ASA disables the user identity rules
associated with the users in that domain. Additionally, the status of all user IP addresses in that domain is
marked as disabled in the Monitoring > Properties > Identity > Users pane.
Step 5 Choose the default domain for the Identity Firewall.

The default domain is used for all users and user groups when a domain has not been explicitly configured
for those users or groups. When a default domain is not specified, the default domain for users and groups is
LOCAL.
Additionally, the Identity Firewall uses the LOCAL domain for all locally defined user groups or locally
defined users (those who log in and authenticate by using a VPN or web portal).
Note The default domain name that you select must match the NetBIOS domain name configured on the
Active Directory domain controller. If the domain name does not match, the AD Agent incorrectly
associates the user-IP mapping with the domain name that you entered when configuring the ASA.
To view the NetBIOS domain name, open the Active Directory user event security log in any text
editor.
For multiple context modes, you can set a default domain name for each context, as well as within
the system execution space.
Step 6 Choose the AD Agent group from the drop-down list. Click Manage to add AD Agent groups.
Step 7 Enter a number between 10 to 65535 seconds in the Hello Timer field.
67
The hello timer between the ASA and the AD Agent defines how frequently the ASA exchanges hello packets.
The ASA uses the hello packet to obtain ASA replication status (in-sync or out-of-sync) and domain status
(up or down). If the ASA does not receive a response from the AD Agent, it resends a hello packet after the
specified interval.
Specify the number of times that the ASA will continue to send hello packets to the AD Agent. By default,
the number of seconds is set to 30 and the retry times is set to 5.
Step 8 Check the Enable Event Timestamp check box to enable the ASA to keep track of the last event time stamp
that it receives for each identifier and to discard any message if the event time stamp is at least 5 minutes
older than the ASA’s clock, or if its time stamp is earlier than the last event’s time stamp.
For a newly booted ASA that does not have knowledge of the last event time stamp, the ASA compares the
event time stamp with its own clock. If the event is at least 5 minutes older, the ASA does not accept the
message.
We recommend that you configure the ASA, Active Directory, and Active Directory agent to synchronize
their clocks among themselves using NTP
Step 9 Enter the number of hours in the Poll Group Timer field that the ASA uses to query the DNS server to resolve
fully qualified domain names (FQDN). By default, the poll timer is set to 4 hours.
Step 10 Choose an option from the list in the Retrieve User Information section:
• On Demand—Specifies that the ASA retrieve the user mapping information of an IP address from the
AD Agent when the ASA receives a packet that requires a new connection and the user of its source IP
address is not in the user-identity database.
• Full Download—Specifies that the ASA send a request to the AD Agent to download the entire IP-user
mapping table when the ASA starts and then to receive incremental IP-user mapping when users log in
and log out.
Note Choosing On Demand has the benefit of using less memory because only users of received
packets are queried and stored.
Step 11 Choose whether or not to disable rules if the AD Agent is not responding.
When the AD Agent is down and this option is selected, the ASA disables the user identity rules associated
with the users in that domain. Additionally, the status of all user IP addresses in that domain are marked as
disabled in the Monitoring > Properties > Identity > Users pane.
Step 12 Choose whether or not to remove a user’s IP address when the NetBIOS probe fails.
Choosing this option specifies the action when NetBIOS probing to a user is blocked (for example, the user
client does not respond to a NetBIOS probe). The network connection might be blocked to that client or the
client is not active. When this option is chosen, the ASA disables the identity rules associated with that user’s
IP address.
Step 13 Choose whether or not to remove a user’s MAC address when it is inconsistent with the IP address that the
ASA has currently mapped to that MAC address. When this option is chosen, the ASA disables the user
identity rules associated with the specific user.
Step 14 Choose whether or not to track users that are not found.
Step 15 Choose the Idle Timeout option and enter a time in minutes, from 1 minute to 65535. By default, the idle
timeout is set to 60 minutes.
Enabling this option configures a timer when an active user is considered idle, meaning the ASA does not
receive traffic from the user’s IP address for more than the specified time. After the timer expires, the user’s
IP address is marked inactive and removed from the local cached IP-user database and the ASA no longer
68
notifies the AD Agent about that IP address. Existing traffic is still allowed to pass. When the Idle Timeout
option is enabled, the ASA runs an inactive timer even when the NetBIOS Logout Probe is configured.
Note The Idle Timeout option does not apply to VPN or cut-through proxy
users.
Step 16 Enable NetBIOS probing and set the probe timer (from 1 to 65535 minutes) before a user's IP addresses is
probed and the retry interval (from 1 to 256 retries) between retry probes.
Enabling this option configures how often the ASA probes the user host to determine whether the user client
is still active. To minimize the NetBIOS packets, ASA only sends a NetBIOS probe to the client when the
user has been idle for more than the specified number of minutes in the Idle Timeout minutes field.
Step 17 Choose an option from the User Name list:

• Match Any—As long as the NetBIOS response from the host includes the username of the user assigned
to the IP address, the user identity is be considered valid. Specifying this option requires that the host
enabled the Messenger service and configured a WINS server.
• Exact Match—The username of the user assigned to the IP address must be the only one in the NetBIOS
response. Otherwise, the user identity of that IP address is considered invalid. Specifying this option
requires that the host enabled the Messenger service and configured a WINS server.
• User Not Needed—As long as the ASA received a NetBIOS response from the host, the user identity
is considered valid.
Step 18 Click Apply to save the Identity Firewall configuration.
Configure Identity-Based Security Policy

You can incorporate identity-based policy in many ASA features. Any feature that uses extended ACLs (other
than those listed as unsupported in the Guidelines section) can take advantage of an identity firewall. You can
now add user identity arguments to extended ACLs, as well as network-based parameters.
Features that can use identity include the following:
• Access rules—An access rule permits or denies traffic on an interface using network information. With
an identity firewall, you can control access based on user identity.
• AAA rules—An authentication rule (also known as cut-through proxy) controls network access based
on the user. Because this function is very similar to an access rule plus an identity firewall, AAA rules
can now be used as a backup method of authentication if a user’s AD login expires. For example, for
any user without a valid login, you can trigger a AAA rule. To ensure that the AAA rule is only triggered
for users that do not have valid logins, you can specify special usernames in the extended ACL used for
the access rule and for the AAA rule: None (users without a valid login) and Any (users with a valid
login). In the access rule, configure your policy as usual for users and groups, but then include a AAA
rule that permits all None users; you must permit these users so they can later trigger a AAA rule. Then,
configure a AAA rule that denies Any users (these users are not subject to the AAA rule, and were
handled already by the access rule), but permits all None users. For example:
access-list 100 ex permit ip user CISCO\xyz any any

access-list 100 ex deny ip user CISCO\abc any any
access-list 100 ex permit ip user NONE any any
access-list 100 ex deny any any
access-group 100 in interface inside
69
Monitoring the Identity Firewall
access-list 200 ex deny ip user ANY any any

access-list 200 ex permit user NONE any any
aaa authenticate match 200 inside user-identity
For more information, see the legacy feature guide.

• Cloud Web Security—You can control which users are sent to the Cloud Web Security proxy server.
In addition, you can configure policy on the Cloud Web Security ScanCenter that is based on user groups
that are included in ASA traffic headers sent to Cloud Web Security.
• VPN filter—Although a VPN does not support identity firewall ACLs in general, you can configure the
ASA to enforce identity-based access rules on VPN traffic. By default, VPN traffic is not subject to
access rules. You can force VPN clients to abide by access rules that use an identity firewall ACL (with
the no sysopt connection permit-vpn command). You can also use an identity firewall ACL with the
VPN filter feature; a VPN filter accomplishes a similar effect by allowing access rules in general.
Monitoring the Identity Firewall

See the following screens for monitoring the Identity Firewall status:
• Monitoring > Properties > Identity > AD Agent
This pane shows the status of the AD Agents and the domains, and the statistics for the AD Agents.
• Monitoring > Properties > Identity > Memory Usage
This pane shows the memory usage that the Identity Firewall consumes on the ASA.
• Monitoring > Properties > Identity > User
• This pane shows information about all users contained in the IP-user mapping database used by the
Identity Firewall.
• Monitoring > Properties > Identity > Group
This pane shows the list of user groups configured for the Identity Firewall.
• Tools > Command Line Interface
This pane allows you to issue various non-interactive commands and view results.
History for the Identity Firewall

Table 3: History for the Identity Firewall

Identity Firewall 8.4(2) The Identity Firewall feature was introduced.
We introduced or modified the following screens:
Configuration > Firewall > Identity Options
Configuration > Firewall > Objects > Local User Groups
Monitoring > Properties > Identity.
70
71
72
CHAPTER 6
ASA and Cisco TrustSec
This chapter describes how to implement Cisco TrustSec for the ASA.
• About Cisco TrustSec, page 73

• Guidelines for Cisco TrustSec, page 80
• Configure the ASA to Integrate with Cisco Trustsec, page 83
• AnyConnect VPN Support for Cisco TrustSec, page 92
• Monitoring Cisco TrustSec, page 93
• History for Cisco TrustSec, page 94
About Cisco TrustSec

Traditionally, security features such as firewalls performed access control based on predefined IP addresses,
subnets, and protocols. However, with enterprises transitioning to borderless networks, both the technology
used to connect people and organizations and the security requirements for protecting data and networks have
evolved significantly. Endpoints are becoming increasingly nomadic and users often employ a variety of
endpoints (for example, laptop versus desktop, smart phone, or tablet), which means that a combination of
user attributes plus endpoint attributes provide the key characteristics (in addition to existing 6-tuple based
rules), that enforcement devices such as switches and routers with firewall features or dedicated firewalls can
reliably use for making access control decisions.
As a result, the availability and propagation of endpoint attributes or client identity attributes have become
increasingly important requirements to enable security across the customers’ networks, at the access, distribution,
and core layers of the network, and in the data center.
Cisco TrustSec provides access control that builds upon an existing identity-aware infrastructure to ensure
data confidentiality between network devices and integrate security access services on one platform. In the
Cisco TrustSec feature, enforcement devices use a combination of user attributes and endpoint attributes to
make role-based and identity-based access control decisions. The availability and propagation of this information
enables security across networks at the access, distribution, and core layers of the network.
Implementing Cisco TrustSec into your environment has the following advantages:
• Provides a growing mobile and complex workforce with appropriate and more secure access from any
device
73
• Lowers security risks by providing comprehensive visibility of who and what is connecting to the wired
or wireless network
• Offers exceptional control over activity of network users accessing physical or cloud-based IT resources
• Reduces total cost of ownership through centralized, highly secure access policy management and
scalable enforcement mechanisms
• For more information, see the following URLs:
Reference Description
http://www.cisco.com/c/en/us/solutions/ Describes the Cisco TrustSec system and architecture for the
enterprise-networks/trustsec/index.html enterprise.
http://www.cisco.com/c/en/us/solutions/ Provides instructions for deploying the Cisco TrustSec solution

enterprise/design-zone-security/landing_ in the enterprise, including links to component design guides.
DesignZone_TrustSec.html
http://www.cisco.com/c/en/us/solutions/ Provides an overview of the Cisco TrustSec solution when used

collateral/enterprise-networks/trustsec/ with the ASA, switches, wireless LAN (WLAN) controllers, and
solution_overview_c22-591771.pdf routers.
http://www.cisco.com/c/en/us/solutions/ Provides the Cisco TrustSec Platform Support Matrix, which lists
enterprise-networks/trustsec/trustsec_ the Cisco products that support the Cisco TrustSec solution.
matrix.html
About SGT and SXP Support in Cisco TrustSec

In the Cisco TrustSec feature, security group access transforms a topology-aware network into a role-based
network, which enables end-to-end policies enforced on the basis of role-based access control (RBAC). Device
and user credentials acquired during authentication are used to classify packets by security groups. Every
packet entering the Cisco TrustSec cloud is tagged with a security group tag (SGT). The tagging helps trusted
intermediaries identify the source identity of the packet and enforce security policies along the data path. An
SGT can indicate a privilege level across the domain when the SGT is used to define a security group ACL.
An SGT is assigned to a device through IEEE 802.1X authentication, web authentication, or MAC authentication
bypass (MAB), which occurs with a RADIUS vendor-specific attribute. An SGT can be assigned statically
to a particular IP address or to a switch interface. An SGT is passed along dynamically to a switch or access
point after successful authentication.
The Security-group eXchange Protocol (SXP) is a protocol developed for Cisco TrustSec to propagate the
IP-to-SGT mapping database across network devices that do not have SGT-capable hardware support to
hardware that supports SGTs and security group ACLs. SXP, a control plane protocol, passes IP-SGT mapping
from authentication points (such as legacy access layer switches) to upstream devices in the network.
The SXP connections are point-to-point and use TCP as the underlying transport protocol. SXP uses the
well-known TCP port number 64999 to initiate a connection. Additionally, an SXP connection is uniquely
identified by the source and destination IP addresses.
74
Roles in the Cisco TrustSec Feature

To provide identity and policy-based access enforcement, the Cisco TrustSec feature includes the following
roles:
• Access Requester (AR)—Access requesters are endpoint devices that request access to protected resources
in the network. They are primary subjects of the architecture and their access privilege depends on their
Identity credentials.
Access requesters include endpoint devices such PCs, laptops, mobile phones, printers, cameras, and
MACsec-capable IP phones.
• Policy Decision Point (PDP)—A policy decision point is responsible for making access control decisions.
The PDP provides features such as 802.1x, MAB, and web authentication. The PDP supports authorization
and enforcement through VLAN, DACL, and security group access (SGACL/SXP/SGT).
In the Cisco TrustSec feature, the Cisco Identity Services Engine (ISE) acts as the PDP. The Cisco ISE
provides identity and access control policy functionality.
• Policy Information Point (PIP)—A policy information point is a source that provides external information
(for example, reputation, location, and LDAP attributes) to policy decision points.
Policy information points include devices such as Session Directory, Sensor IPS, and Communication
Manager.
• Policy Administration Point (PAP)—A policy administration point defines and inserts policies into the
authorization system. The PAP acts as an identity repository by providing Cisco TrustSec tag-to-user
identity mapping and Cisco TrustSec tag-to-server resource mapping.
In the Cisco TrustSec feature, the Cisco Secure Access Control System (a policy server with integrated
802.1x and SGT support) acts as the PAP.
• Policy Enforcement Point (PEP)—A policy enforcement point is the entity that carries out the decisions
(policy rules and actions) made by the PDP for each AR. PEP devices learn identity information through
the primary communication path that exists across networks. PEP devices learn the identity attributes
of each AR from many sources, such as endpoint agents, authorization servers, peer enforcement devices,
and network flows. In turn, PEP devices use SXP to propagate IP-SGT mapping to mutually trusted
peer devices across the network.
Policy enforcement points include network devices such as Catalyst switches, routers, firewalls
(specifically the ASA), servers, VPN devices, and SAN devices.
The Cisco ASA serves the PEP role in the identity architecture. Using SXP, the ASA learns identity information
directly from authentication points and uses it to enforce identity-based policies.
Security Group Policy Enforcement

Security policy enforcement is based on security group name. An endpoint device attempts to access a resource
in the data center. Compared to traditional IP-based policies configured on firewalls, identity-based policies
are configured based on user and device identities. For example, mktg-contractor is allowed to access
mktg-servers; mktg-corp-users are allowed to access mktg-server and corp-servers.
The benefits of this type of deployment include the following:
• User group and resource are defined and enforced using single object (SGT) simplified policy
management.
75
• User identity and resource identity are retained throughout the Cisco TrustSec-capable switch
infrastructure.
The following figure shows a deployment for security group name-based policy enforcement.
Figure 10: Security Group Name-Based Policy Enforcement Deployment
Implementing Cisco TrustSec allows you to configure security policies that support server segmentation and
includes the following features:
• A pool of servers can be assigned an SGT for simplified policy management.
• The SGT information is retained within the infrastructure of Cisco TrustSec-capable switches.
• The ASA can use the IP-SGT mapping for policy enforcement across the Cisco TrustSec domain.
• Deployment simplification is possible because 802.1x authorization for servers is mandatory.
How the ASA Enforces Security Group-Based Policies
Note User-based security policies and security-group based policies can coexist on the ASA. Any combination
of network, user-based, and security-group based attributes can be configured in a security policy.
To configure the ASA to function with Cisco TrustSec, you must import a Protected Access Credential (PAC)
file from the ISE.
Importing the PAC file to the ASA establishes a secure communication channel with the ISE. After the channel
is established, the ASA initiates a PAC secure RADIUS transaction with the ISE and downloads Cisco TrustSec
environment data (that is, the security group table). The security group table maps SGTs to security group
names. Security group names are created on the ISE and provide user-friendly names for security groups.
The first time that the ASA downloads the security group table, it walks through all entries in the table and
resolves all the security group names included in security policies that have been configured on it; then the
ASA activates those security policies locally. If the ASA cannot resolve a security group name, it generates
a syslog message for the unknown security group name.
76
The following figure shows how a security policy is enforced in Cisco TrustSec.
Figure 11: Security Policy Enforcement
1 An endpoint device connects to an access layer device directly or via remote access and authenticates with
Cisco TrustSec.
2 The access layer device authenticates the endpoint device with the ISE by using authentication methods
such as 802.1X or web authentication. The endpoint device passes role and group membership information
to classify the device into the appropriate security group.
3 The access layer device uses SXP to propagate the IP-SGT mapping to the upstream devices.
4 The ASA receives the packet and looks up the SGTs for the source and destination IP addresses using the
IP-SGT mapping passed by SXP.
If the mapping is new, the ASA records it in its local IP-SGT Manager database. The IP-SGT Manager
database, which runs in the control plane, tracks IP-SGT mapping for each IPv4 or IPv6 address. The
database records the source from which the mapping was learned. The peer IP address of the SXP connection
is used as the source of the mapping. Multiple sources can exist for each IP-SGT mapped entry.
If the ASA is configured as a Speaker, the ASA transmits all IP-SGT mapping entries to its SXP peers.
5 If a security policy is configured on the ASA with that SGT or security group name, the ASA enforces
the policy. (You can create security policies on the ASA that include SGTs or security group names. To
enforce policies based on security group names, the ASA needs the security group table to map security
group names to SGTs.)
If the ASA cannot find a security group name in the security group table and it is included in a security
policy, the ASA considers the security group name to be unknown and generates a syslog message. After
the ASA refreshes the security group table from the ISE and learns the security group name, the ASA
generates a syslog message indicating that the security group name is known.
Effects of Changes to Security Groups on the ISE

The ASA periodically refreshes the security group table by downloading an updated table from the ISE.
Security groups can change on the ISE between downloads. These changes are not reflected on the ASA until
it refreshes the security group table.
77
Tip We recommend that you schedule policy configuration changes on the ISE during a maintenance window,
then manually refresh the security group table on the ASA to make sure the security group changes have
been incorporated.
Handling policy configuration changes in this way maximizes the chances of security group name resolution
and immediate activation of security policies.
The security group table is automatically refreshed when the environment data timer expires. You can also
trigger a security group table refresh on demand.
If a security group changes on the ISE, the following events occur when the ASA refreshes the security group
table:
• Only security group policies that have been configured using security group names need to be resolved
with the security group table. Policies that include security group tags are always active.
• When the security group table is available for the first time, all policies with security group names are
walked through, security group names are resolved, and policies are activated. All policies with tags are
walked through, and syslogs are generated for unknown tags.
• If the security group table has expired, policies continue to be enforced according to the most recently
downloaded security group table until you clear it, or a new table becomes available.
• When a resolved security group name becomes unknown on the ASA, it deactivates the security policy;
however, the security policy persists in the ASA running configuration.
• If an existing security group is deleted on the PAP, a previously known security group tag can become
unknown, but no change in policy status occurs on the ASA. A previously known security group name
can become unresolved, and the policy is then inactivated. If the security group name is reused, the
policy is recompiled using the new tag.
• If a new security group is added on the PAP, a previously unknown security group tag can become
known, a syslog message is generated, but no change in policy status occurs. A previously unknown
security group name can become resolved, and associated policies are then activated.
• If a tag has been renamed on the PAP, policies that were configured using tags display the new name,
and no change in policy status occurs. Policies that were configured with security group names are
recompiled using the new tag value.
Speaker and Listener Roles on the ASA

The ASA supports SXP to send and receive IP-SGT mapping entries to and from other network devices. Using
SXP allows security devices and firewalls to learn identity information from access switches without the need
for hardware upgrades or changes. SXP can also be used to pass IP-SGT mapping entries from upstream
devices (such as data center devices) back to downstream devices. The ASA can receive information from
both upstream and downstream directions.
When configuring an SXP connection on the ASA to an SXP peer, you must designate the ASA as a Speaker
or a Listener for that connection so that it can exchange Identity information:
• Speaker mode—Configures the ASA so that it can forward all active IP-SGT mapping entries collected
on the ASA to upstream devices for policy enforcement.
78
• Listener mode—Configures the ASA so that it can receive IP-SGT mapping entries from downstream
devices (SGT-capable switches) and use that information to create policy definitions.
If one end of an SXP connection is configured as a Speaker, then the other end must be configured as a
Listener, and vice versa. If both devices on each end of an SXP connection are configured with the same role
(either both as Speakers or both as Listeners), the SXP connection fails and the ASA generates a syslog
message.
Multiple SXP connections can learn IP-SGT mapping entries that have been downloaded from the IP-SGT
mapping database. After an SXP connection to an SXP peer is established on the ASA, the Listener downloads
the entire IP-SGT mapping database from the Speaker. All changes that occur after this are sent only when a
new device appears on the network. As a result, the rate of SXP information flow is proportional to the rate
at which end hosts authenticate to the network.
IP-SGT mapping entries that have been learned through SXP connections are maintained in the SXP IP-SGT
mapping database. The same mapping entries may be learned through different SXP connections. The mapping
database maintains one copy for each mapping entry learned. Multiple mapping entries of the same IP-SGT
mapping value are identified by the peer IP address of the connection from which the mapping was learned.
SXP requests that the IP-SGT Manager add a mapping entry when a new mapping is learned the first time
and remove a mapping entry when the last copy in the SXP database is removed.
Whenever an SXP connection is configured as a Speaker, SXP requests that the IP-SGT Manager forward all
the mapping entries collected on the device to the peer. When a new mapping is learned locally, the IP-SGT
Manager requests that SXP forward it through connections that are configured as Speakers.
Configuring the ASA to be both a Speaker and a Listener for an SXP connection can cause SXP looping,
which means that SXP data can be received by an SXP peer that originally transmitted it.
Register the ASA with the ISE

The ASA must be configured as a recognized Cisco TrustSec network device in the ISE before the ASA can
successfully import a PAC file. To register the ASA with the ISE, perform the following steps:
Procedure
Step 1 Log into the ISE.

Step 2 Choose Administration > Network Devices > Network Devices.
Step 3 Click Add.
Step 4 Enter the IP address of the ASA.
Step 5 When the ISE is being used for user authentication, enter a shared secret in the Authentication Settings area.
When you configure the AAA sever on the ASA, provide the shared secret that you create here on the ISE.
The AAA server on the ASA uses this shared secret to communicate with the ISE.
Step 6 Specify a device name, device ID, password, and a download interval for the ASA. See the ISE documentation
for how to perform these tasks.
79
Guidelines for Cisco TrustSec
Create a Security Group on the ISE

When configuring the ASA to communicate with the ISE, you specify a AAA server. When configuring the
AAA server on the ASA, you must specify a server group. The security group must be configured to use the
RADIUS protocol. To create a security group on the ISE, perform the following steps:
Procedure

Step 2 Choose Policy > Policy Elements > Results > Security Group Access > Security Group.
Step 3 Add a security group for the ASA. (Security groups are global and not ASA specific.)
The ISE creates an entry under Security Groups with a tag.
Step 4 In the Security Group Access area, configure device ID credentials and a password for the ASA.
Generate the PAC File

To generate the PAC file, perform the following steps.
Note The PAC file includes a shared key that allows the ASA and ISE to secure the RADIUS transactions that
occur between them. For this reason, make sure that you store it securely on the ASA.
Procedure

Step 2 Choose Administration > Network Resources > Network Devices.
Step 3 From the list of devices, choose the ASA.
Step 4 Under the Security Group Access (SGA), click Generate PAC.
Step 5 To encrypt the PAC file, enter a password.
The password (or encryption key) that you enter to encrypt the PAC file is independent of the password that
was configured on the ISE as part of the device credentials.
The ISE generates the PAC file. The ASA can import the PAC file from flash or from a remote server via
TFTP, FTP, HTTP, HTTPS, or SMB. (The PAC file does not have to reside on the ASA flash before you can
import it.)

This section includes the guidelines and limitations that you should review before configuring Cisco TrustSec.
80
Failover
• You can configure security group-based policies on the ASA in both the Active/Active and Active/Standby
configurations.
• When the ASA is part of a failover configuration, you must import the PAC file to the primary ASA
device. You must also refresh the environment data on the primary device.
• The ASA can communicate with the ISE configured for high availability (HA).
• You can configure multiple ISE servers on the ASA and if the first server is unreachable, it continues
to the next server, and so on. However, if the server list is downloaded as part of the Cisco TrustSec
environment data, it is ignored.
• If the PAC file downloaded from the ISE expires on the ASA and it cannot download an updated security
group table, the ASA continues to enforce security policies based on the last downloaded security group
table until the ASA downloads an updated table.
Clustering
• When the ASA is part of a clustering configuration, you must import the PAC file to the master unit.
• When the ASA is part of a clustering configuration, you must refresh the environment data on the master
unit.
IPv6
The ASA supports SXP for IPv6 and IPv6-capable network devices. The AAA server must use an IPv4
address.
Layer 2 SGT Imposition

• Supported only on physical interfaces, VLAN interfaces, port channel interfaces, and redundant interfaces.
• Not supported on logical interfaces or virtual interfaces, such as BVI.
• Does not support link encryption using SAP negotiation and MACsec.
• Not supported on failover links.
• Not supported on cluster control links.
• The ASA does not reclassify existing flows if the SGT is changed. Any policy decisions that were made
based on the previous SGT remain in force for the life of the flow. However, the ASA can immediately
reflect SGT changes on egress packets, even if the packets belong to a flow whose classification was
based on a previous SGT.
• The hardware architecture of the ASA 5585-X is designed to load balance regular packets in an optimal
way, but this is not the case for inline tagged packets with Layer 2 Security Group Tagging Imposition.
Significant performance degradation on the ASA 5585-X may occur when it processes incoming inline
tagged packets. This issue does not occur with inline tagged packets on other ASA platforms, as well
as with untagged packets on the ASA 5585-X. One workaround is to offload access policies so that
minimal inline tagged packets go to the ASA 5585-X, which allows the switches to handle tagged policy
enforcement. Another workaround is to use SXP so that the ASA 5585-X can map the IP address to the
security group tag without the need to receive tagged packets.
• The ASASM does not support Layer 2 Security Group Tagging Imposition.
81
• The ASA supports SXP Version 2. The ASA negotiates SXP versions with different SXP-capable
network devices.
• You can configure the ASA to refresh the security group table when the SXP reconcile timer expires
and you can download the security group table on demand. When the security group table on the ASA
is updated from the ISE, changes are reflected in the appropriate security policies.
• Cisco TrustSec supports the Smart Call Home feature in single context and multi-context mode, but not
in the system context.
• The ASA can only be configured to interoperate in a single Cisco TrustSec domain.
• The ASA does not support static configuration of SGT-name mapping on the device.
• NAT is not supported in SXP messages.
• SXP conveys IP-SGT mapping to enforcement points in the network. If an access layer switch belongs
to a different NAT domain than the enforcing point, the IP-SGT map that it uploads is invalid, and an
IP-SGT mapping database lookup on the enforcement device does not yield valid results. As a result,
the ASA cannot apply security group-aware security policy on the enforcement device.
• You can configure a default password for the ASA to use for SXP connections, or you can choose not
to use a password; however, connection-specific passwords are not supported for SXP peers. The
configured default SXP password should be consistent across the deployment network. If you configure
a connection-specific password, connections may fail and a warning message appears. If you configure
the connection with the default password, but it is not configured, the result is the same as when you
have configured the connection with no password.
• The ASA can be configured as an SXP Speaker or Listener, or both. However, SXP connection loops
can form when a device has bidirectional connections to a peer or is part of a unidirectionally connected
chain of devices. (The ASA can learn IP-SGT mapping for resources from the access layer in the data
center. The ASA might need to propagate these tags to downstream devices.) SXP connection loops can
cause unexpected behavior of SXP message transport. In cases where the ASA is configured to be a
Speaker and Listener, an SXP connection loop can occur, causing SXP data to be received by the peer
that originally transmitted it.
• When changing the ASA local IP address, you must ensure that all SXP peers have updated their peer
list. In addition, if SXP peers changes its IP addresses, you must ensure those changes are reflected on
the ASA.
• Automatic PAC file provisioning is not supported. The ASA administrator must request the PAC file
from the ISE administrative interface and import it into the ASA.
• PAC files have expiration dates. You must import the updated PAC file before the current PAC file
expires; otherwise, the ASA cannot retrieve environment data updates. If the PAC file downloaded from
the ISE expires on the ASA and it cannot download an updated security group table, the ASA continues
to enforce security policies based on the last downloaded security group table until the ASA downloads
an updated table.
• When a security group changes on the ISE (for example, it is renamed or deleted), the ASA does not
change the status of any ASA security policies that contain an SGT or security group name associated
with the changed security group; however, the ASA generates a syslog message to indicate that those
security policies changed.
• The multi-cast types are not supported in ISE 1.0.
82
Configure the ASA to Integrate with Cisco Trustsec
• An SXP connection stays in the initializing state among two SXP peers interconnected by the ASA; as
shown in the following example:
(SXP peer A) - - - - (ASA) - - - (SXP peer B)
Therefore, when configuring the ASA to integrate with Cisco TrustSec, you must enable the no-NAT,
no-SEQ-RAND, and MD5-AUTHENTICATION TCP options on the ASA to configure SXP connections.
Create a TCP state bypass policy for traffic destined to SXP port TCP 64999 among the SXP peers.
Then apply the policy on the appropriate interfaces.
For example, the following set of commands shows how to configure the ASA for a TCP state bypass
policy:
access-list SXP-MD5-ACL extended permit tcp host peerA host peerB eq 64999
access-list SXP-MD5-ACL extended permit tcp host peerB host peerA eq 64999
tcp-map SXP-MD5-OPTION-ALLOW
tcp-options range 19 19 allow
class-map SXP-MD5-CLASSMAP
match access-list SXP-MD5-ACL
policy-map type inspect dns preset_dns_map

parameters
message-length maximum 512
policy-map global_policy
class SXP-MD5-CLASSMAP
set connection random-sequence-number disable
set connection advanced-options SXP-MD5-OPTION-ALLOW
set connection advanced-options tcp-state-bypass
service-policy global_policy global

To configure the ASA to integrate with Cisco TrustSec, perform the following tasks.
Before You Begin

Before configuring the ASA to integrate with Cisco TrustSec, you must complete the following tasks in ISE:
• Register the ASA with the ISE, on page 79
• Create a Security Group on the ISE, on page 80
• Generate the PAC File, on page 80
Procedure
Step 1 Configure the AAA Server for Cisco TrustSec Integration, on page 84
Step 2 Import a PAC File, on page 85
Step 3 Configure the Security Exchange Protocol, on page 86
This task enables and sets the default values for SXP.
Step 4 Add an SXP Connection Peer, on page 87

Step 5 Refresh Environment Data, on page 88
83
Do this as needed.
Step 6 Configure the Security Policy, on page 88

Step 7 Configure Layer 2 Security Group Tagging Imposition, on page 89
Configure the AAA Server for Cisco TrustSec Integration

This section describes how to integrate the AAA server for Cisco TrustSec. To configure the AAA server
group to communicate with the ISE on the ASA, perform the following steps.
Before You Begin

• The referenced server group must be configured to use the RADIUS protocol. If you add a non-RADIUS
server group to the ASA, the configuration fails.
• If the ISE is also used for user authentication, obtain the shared secret that was entered on the ISE when
you registered the ASA with the ISE. Contact your ISE administrator to obtain this information.
Procedure
Step 1 Choose Configuration > Firewall > Identity By TrustSec.

Step 2 Click Manage to add a server group to the ASA.
The Configure AAA Server Group dialog box appears.
Step 3 Enter the name of the security group that was created on the ISE for the ASA.
The server group name you specify here must match the name of the security group that was created on the
ISE for the ASA. If these two group names do not match, the ASA cannot communicate with the ISE. Contact
your ISE administrator to obtain this information.
Step 4 Choose RADIUS from the Protocol drop-down list.

To complete the remaining fields in the AAA Server Group dialog box, see the RADIUS chapter in the
general operations configuration guide.
Step 5 Click OK.

Step 6 Select the AAA sever group that you just created and click Add in the Servers in the Selected Group area
to add a server to a group.
The Add AAA Server dialog box appears.
Step 7 Select the network interface where the ISE server resides.
Step 8 Enter the IP address of the ISE server.
To complete the remaining fields in the AAA Server dialog box, see the RADIUS chapter in the general
operations configuration guide.
Step 9 Click OK.

Step 10 Click Apply to save the changes to the running configuration.
84
Import a PAC File

This section describes how to import a PAC file.
Before You Begin

• The ASA must be configured as a recognized Cisco TrustSec network device in the ISE before the ASA
can generate a PAC file.
• Obtain the password used to encrypt the PAC file when generating it on the ISE. The ASA requires this
password to import and decrypt the PAC file.
• The ASA requires access to the PAC file generated by the ISE. The ASA can import the PAC file from
flash or from a remote server via TFTP, FTP, HTTP, HTTPS, or SMB. (The PAC file does not need to
reside on the ASA flash before you can import it.)
• The server group has been configured for the ASA.
To import a PAC file, perform the following steps:
Procedure

Step 2 Check the Enable Security Exchange Protocol check box to enable SXP.
Step 3 Click Import PACto display theImport PAC dialog box.
Step 4 Enter the path and filename for the PAC file by using one of the following formats:
• disk0: Path and filename on disk0
• disk1: Path and filename on disk1
• flash: Path and filename on flash
• ftp: Path and filename on FTP
• http: Path and filename on HTTP
• https: Path and filename on HTTPS
• smb: Path and filename on SMB
• tftp: Path and filename on TFTP
Multi-mode
• http: Path and filename on HTTP

• https: Path and filename on HTTPS
• smb: Path and filename on SMB
• tftp: Path and filename on TFTP
85
Step 5 Enter the password used to encrypt the PAC file. The password is independent of the password that was
configured on the ISE as part of the device credentials.
Step 6 Reenter the password to confirm it.
Step 7 Click Import.
When you import the PAC file, the file is converted to ASCII HEX format and sent to the ASA in
non-interactive mode.
Configure the Security Exchange Protocol

You need to enable and configure the Security Exchange Protocol (SXP) to use Cisco Trustsec.
Before You Begin

At least one interface must be in the UP/UP state. If you enable SXP with all interfaces down, the ASA does
not display a message indicating that SXP is not working or it could not be enabled. If you check the
configuration by entering the show running-config command, the command output displays the following
message:
“WARNING: SXP configuration in process, please wait for a few moments and try again.”
Procedure

Step 2 Check the Enable Security Exchange Protocol check box to enable SXP. By default, SXP is disabled.
Step 3 (Optional; not recommended.) Enter the default local IP address for SXP connections. The IP address can be
an IPv4 or IPv6 address.
Note The ASA determines the local IP address for an SXP connection as the outgoing interface IP address
that is reachable by the peer IP address. If the configured local address is different from the outgoing
interface IP address, the ASA cannot connect to the SXP peer and generates a syslog message. We
recommend that you do not configure a default source IP address for SXP connections and allow the
ASA to perform a route/ARP lookup to determine the source IP address for an SXP connection.
Step 4 (Optional.) Enter the default password for TCP MD5 authentication with SXP peers. By default, SXP
connections do not have a password set.
Configure a default password if and only if you configure the SXP connection peers to use the default password.
The password can be up to 80 characters. It is not encrypted.
Step 5 (Optional.) Change the time interval between ASA attempts to set up new SXP connections between SXP
peers in the Retry Timer field.
The ASA continues to make connection attempts until a successful connection is made, waiting the retry
interval before trying again after a failed attempt. You can specify a retry period from 0 to 64000 seconds.
The default is 120 seconds. If you specify 0 seconds, the ASA does not try to connect to SXP peers.
We recommend that you configure the retry timer to a different value from its SXP peer devices.
Step 6 (Optional.) Change the reconcile timer value.
86
After an SXP peer terminates its SXP connection, the ASA starts a hold down timer. If an SXP peer connects
while the hold down timer is running, the ASA starts the reconciliation timer; then, the ASA updates the SXP
mapping database to learn the latest mappings.
When the reconciliation timer expires, the ASA scans the SXP mapping database to identify stale mapping
entries (which were learned in a previous connection session). The ASA marks these connections as obsolete.
When the reconciliation timer expires, the ASA removes the obsolete entries from the SXP mapping database.
You can specify a reconciliation period from 1 to 64000 seconds. The default is 120 seconds.
Add an SXP Connection Peer

To add an SXP connection peer, perform the following steps:
Procedure

Step 2 Click Addto display the Add Connection dialog box.
Step 3 Enter the IPv4 or IPv6 address of the SXP peer. The peer IP address must be reachable from the ASA outgoing
interface.
Step 4 Indicate whether or not to use the authentication key for the SXP connection by choosing one of the following
values:
• Default—Use the default password configured for SXP connections.
• None—Do not use a password for the SXP connection.
Step 5 (Optional) Specify the mode of the SXP connection by choosing one of the following values:
• Local—Use the local SXP device.
• Peer—Use the peer SXP device.
Step 6 Specify whether the ASA functions as a Speaker or Listener for the SXP connection:
• Speaker—The ASA can forward IP-SGT mapping to upstream devices.
• Listener—The ASA can receive IP-SGT mapping from downstream devices.
Step 7 (Optional) Click Advanced and enter the local IPv4 or IPv6 address of the SXP connection.
The ASA uses a route lookup to determine the right interface. If you specify an address, it must match the
route lookup interface address of the outbound interface. We recommend that you do not configure a source
IP address for an SXP connection and allow the ASA to perform a route/ARP lookup to determine the source
IP address for the SXP connection.
Step 8 Click OK.

Step 9 Click Apply to save your settings to the running configuration.
87
Refresh Environment Data

The ASA downloads environment data from the ISE, which includes the Security Group Tag (SGT) name
table. The ASA automatically refreshes its environment data that is obtained from the ISE when you complete
the following tasks on the ASA:
• Configure a AAA server to communicate with the ISE.
• Import a PAC file from the ISE.
• Identify the AAA server group that the ASA will use to retrieve Cisco TrustSec environment data.
Normally, you do not need to manually refresh the environment data from the ISE; however, security groups
can change on the ISE. These changes are not reflected on the ASA until you refresh the data in the ASA
security group table, so refresh the data on the ASA to make sure that any security group changes made on
the ISE are reflected on the ASA.
Note We recommend that you schedule policy configuration changes on the ISE and the manual data refresh
on the ASA during a maintenance window. Handling policy configuration changes in this way maximizes
the chances of security group names getting resolved and security policies becoming active immediately
on the ASA.
To refresh the environment data, perform the following steps:
Procedure

Step 2 Click Refresh Environment > Data in the Server Group Setup area.
The ASA refreshes the Cisco TrustSec environment data from the ISE and resets the reconcile timer to the
configured default value.
Configure the Security Policy

You can incorporate Cisco TrustSec policy in many ASA features. Any feature that uses extended ACLs
(unless listed in this chapter as unsupported) can take advantage of Cisco TrustSec. You can add security
group arguments to extended ACLs, as well as traditional network-based parameters.
• To configure access rules, see Configure Access Rules, on page 17. For other extended ACLs, see
Configure Extended ACLs.
• To configure security group object groups that can be used in the ACL, see Configure Security Group
Object Groups, on page 34.
For example, an access rule permits or denies traffic on an interface using network information. With Cisco
TrustSec, you can control access based on security group. For example, you could create an access rule for
sample_securitygroup1 10.0.0.0 255.0.0.0, meaning the security group could have any IP address on subnet
10.0.0.0/8.
88
You can configure security policies based on combinations of security group names (servers, users, unmanaged
devices, and so on), user-based attributes, and traditional IP-address-based objects (IP address, Active Directory
object, and FQDN). Security group membership can extend beyond roles to include device and location
attributes and is independent of user group membership.
Configure Layer 2 Security Group Tagging Imposition

Cisco TrustSec identifies and authenticates each network user and resource and assigns a 16-bit number called
a Security Group Tag (SGT). This identifier is in turn propagated between network hops, which allows any
intermediary devices such as ASAs, switches, and routers to enforce polices based on this identity tag.
SGT plus Ethernet Tagging, also called Layer 2 SGT Imposition, enables the ASA to send and receive security
group tags on Ethernet interfaces using Cisco proprietary Ethernet framing (EtherType 0x8909), which allows
the insertion of source security group tags into plain-text Ethernet frames. The ASA inserts security group
tags on the outgoing packet and processes security group tags on the incoming packet, based on a manual
per-interface configuration. This feature allows inline hop-by-hop propagation of endpoint identity across
network devices and provides seamless Layer 2 SGT Imposition between each hop.
The following figure shows a typical example of Layer 2 SGT Imposition.
Figure 12: Layer 2 SGT Imposition
Usage Scenarios
The following table describes the expected behavior for ingress traffic when configuring this feature.
Table 4: Ingress Traffic
Interface Configuration Tagged Packet Received Untagged Packet Received

No command is issued. Packet is dropped. SGT value is from the IP-SGT Manager.
89
Interface Configuration Tagged Packet Received Untagged Packet Received

The cts manual command is issued. SGT value is from the IP-SGT Manager. SGT value is from the IP-SGT Manager.
The cts manual command and the policy SGT value is from the policy static sgt SGT value is from the policy static sgt
static sgt sgt_number command are both sgt_number command. sgt_number command.
issued.
The cts manual command and the policy SGT value is from the inline SGT in the SGT value is from the policy static sgt
static sgt sgt_number trusted command packet. sgt_number command.
are both issued.
Note If there is no matched IP-SGT mapping from the IP-SGT Manager, then a reserved SGT value of “0x0”
for “Unknown” is used.
The following table describes the expected behavior for egress traffic when configuring this feature.
Table 5: Egress Traffic
Interface Configuration Tagged or Untagged Packet Sent

No command is issued. Untagged
The cts manual command is issued. Tagged
The cts manual command and the propagate sgt command are both Tagged
issued.
The cts manual command and the no propagate sgt command are both Untagged
issued.
The following table describes the expected behavior for to-the-box and from-the-box traffic when configuring
this feature.
Table 6: To-the-box and From-the-box Traffic
Interface Configuration Tagged or Untagged Packet Received

No command is issued on the ingress interface for Packet is dropped.
to-the-box traffic.
The cts manual command is issued on the ingress Packet is accepted, but there is no policy enforcement
interface for to-the-box traffic. or SGT propagation.
90
Interface Configuration Tagged or Untagged Packet Received

The cts manual command is not issued or the cts Untagged packet is sent, but there is no policy
manual command and no propagate sgt command enforcement. The SGT number is from the IP-SGT
are both issued on the egress interface for Manager.
from-the-box traffic.
The cts manual command is issued or the cts manual Tagged packet is sent. The SGT number is from the
command and the propagate sgt command are both IP-SGT Manager.
issued on the egress interface for from-the-box traffic.
Note If there is no matched IP-SGT mapping from the IP-SGT Manager, then a reserved SGT value of “0x0”
for “Unknown” is used.
Configure a Security Group Tag on an Interface

To configure a security group tag on an interface, perform the following steps:
Procedure
Step 1 Choose one of the following options:

• Configuration > Device Setup > Interfaces> Add Interface > Advanced
• Configuration > Device Setup > Interfaces > Add Redundant Interface > Advanced
• Configuration > Device Setup > Interfaces > Add Ethernet Interface > Advanced
Step 2 Check the Enable secure group tagging for Cisco TrustSec check box.
Step 3 Check the Tag egress packets with service group tags check box.
Step 4 Check the Add a static secure group tag to all ingress packets check box.
Step 5 Enter a secure group tag number. Valid values range from 2 - 65519.
Step 6 Check the This is a trusted interface. Do not override existing secure group tags check box.
Step 7 Click OK to save your settings.
Configure IP-SGT Bindings Manually

To configure IP-SGT bindings manually, perform the following steps:
91
AnyConnect VPN Support for Cisco TrustSec
Procedure
Step 1 Choose Configuration > Firewall Identity by TrustSec.

Step 2 Click Add in the SGT Map Setup area, or select an SGT map and click Edit.
Step 3 In the SGT Map dialog box, enter the SGT Map IP address and the SGT value in the appropriate fields.
SGT numbers can be from 2 to 65519.
Step 4 Click OK, then click Apply to save your settings.
AnyConnect VPN Support for Cisco TrustSec

ASA fully supports security group tagging of VPN sessions. A Security Group Tag (SGT) can be assigned
to a VPN session using an external AAA server, or by configuration of the local user database. This tag can
then be propagated through the Cisco TrustSec system over Layer 2 Ethernet. Security group tags are useful
on group policies and for local users when the AAA server cannot provide an SGT.
If there is no SGT in the attributes from the AAA server to assign to a VPN user, then the ASA uses the SGT
in the default group policy. If there is no SGT in the group policy, then tag 0x0 is assigned.
Connect to a Server for Remote Users

To connect to a server, perform the following steps:
Procedure
Step 1 A user connects to the ASA.

Step 2 The ASA requests AAA information from the ISE, which may include an SGT. The ASA also assigns an IP
address for the user’s tunneled traffic.
Step 3 The ASA uses AAA information to authenticate and creates a tunnel.
Step 4 The ASA uses the SGT from AAA information and the assigned IP address to add an SGT in the Layer 2
header.
Step 5 Packets that include the SGT are passed to the next peer device in the Cisco TrustSec network.
Add an SGT to Local Users and Groups

To configure an SGT attribute on the LOCAL user database and in a group policy, perform the following
steps:
Procedure
Choose one of the following options:

• Configuration > Remote Access VPN > AAA/Local Users > Local Users
92
Monitoring Cisco TrustSec
a) Select a user, then click Edit.

b) Click VPN Policy.
c) Enter a value in the Security Group Tag (STG) field.
d) Click OK.
• Configuration > Remote Access VPN > Network (Client) Access > Group Policies
a) Click the General tab, then click More Options.

b) Enter a value in the Security Group Tag (STG) field.
c) Click OK.
Monitoring Cisco TrustSec

See the following screens for monitoring Cisco TrustSec:
• Monitoring > Properties > Identity By TrustSec > SXP Connections
Shows the configured default values for the Cisco TrustSec infrastructure and the SXP commands.
• Monitoring > Properties > Connections
Filters the IP address-security group table mapping entries so that you view the data by security group
table value, security group name, or IP address.
• Monitoring > Properties > Identity By TrustSec > Environment Data
Shows the Cisco TrustSec environment information contained in the security group table on the ASA.
• Monitoring > Properties > Identity By TrustSec > IP Mapping
Filters the IP address-security group table mapping entries so that you view the data by security group
table value, security group name, or IP address. Click Where Used to show where the selected security
group object is used in an ACL or nested in another security group object.
• Monitoring > Properties > Identity By TrustSec > PAC
Shows information about the PAC file imported into the ASA from the ISE and includes a warning
message when the PAC file has expired or is within 30 days of expiration.
93
History for Cisco TrustSec
History for Cisco TrustSec

Table 7: History for Cisco TrustSec
Platform
Cisco TrustSec 9.0(1) Cisco TrustSec provides access control that builds on an existing
identity-aware infrastructure to ensure data confidentiality between network
devices and integrate security access services on one platform. In the Cisco
TrustSec feature, enforcement devices use a combination of user attributes
and endpoint attributes to make role-based and identity-based access
control decisions.
In this release, the ASA integrates with Cisco TrustSec to provide security
group-based policy enforcement. Access policies within the Cisco TrustSec
domain are topology-independent, based on the roles of source and
destination devices rather than on network IP addresses.
The ASA can use Cisco TrustSec for other types of security group-based
policies, such as application inspection; for example, you can configure
a class map that includes an access policy based on a security group.
Configuration > Firewall > Identity By TrustSec Configuration > Firewall
> Objects > Security Groups Object Groups Configuration > Firewall >
Access Rules > Add Access Rules Monitoring > Properties > Identity By
Tag.
Layer 2 Security Group Tag 9.3(1) You can now use security group tagging combined with Ethernet tagging
Imposition to enforce policies. SGT plus Ethernet Tagging, also called Layer 2 SGT
Imposition, enables the ASA to send and receive security group tags on
Ethernet interfaces using Cisco proprietary Ethernet framing (EtherType
0x8909), which allows the insertion of source security group tags into
plain-text Ethernet frames.
Configuration > Device Setup > Interfaces > Add Interface > Advanced
Configuration > Device Setup > Interfaces > Add Redundant Interface >
Advanced Configuration > Device Setup > Add Ethernet Interface >
Advanced.
94
CHAPTER 7
ASA FirePOWER Module
The following topics describe how to configure the ASA FirePOWER module that runs on the ASA.
• About the ASA FirePOWER Module, page 95

• Licensing Requirements for the ASA FirePOWER Module, page 99
• Guidelines for ASA FirePOWER, page 100
• Defaults for ASA FirePOWER, page 101
• Perform Initial ASA FirePOWER Setup, page 101
• Configure the ASA FirePOWER Module, page 109
• Managing the ASA FirePOWER Module, page 112
• Monitoring the ASA FirePOWER Module, page 120
• History for the ASA FirePOWER Module, page 122
About the ASA FirePOWER Module

The ASA FirePOWER module supplies next-generation firewall services, including Next-Generation Intrusion
Prevention System (NGIPS), Application Visibility and Control (AVC), URL filtering, and Advanced Malware
Protection (AMP).
The ASA FirePOWER module runs a separate application from the ASA. The module can be a hardware
module (on the ASA 5585-X only) or a software module (all other models).
How the ASA FirePOWER Module Works with the ASA

You can configure your ASA FirePOWER module using one of the following deployment models:
• Inline mode—In an inline deployment, the actual traffic is sent to the ASA FirePOWER module, and
the module’s policy affects what happens to the traffic. After dropping undesired traffic and taking any
other actions applied by policy, the traffic is returned to the ASA for further processing and ultimate
transmission.
95
• Inline tap monitor-only mode (ASA inline)—In an inline tap monitor-only deployment, a copy of the
traffic is sent to the ASA FirePOWER module, but it is not returned to the ASA. Inline tap mode lets
you see what the ASA FirePOWER module would have done to traffic, and lets you evaluate the content
of the traffic, without impacting the network. However, in this mode, the ASA does apply its policies
to the traffic, so traffic can be dropped due to access rules, TCP normalization, and so forth.
• Passive monitor-only (traffic forwarding) mode—If you want to prevent any possibility of the ASA with
FirePOWER Services device impacting traffic, you can configure a traffic-forwarding interface and
connect it to a SPAN port on a switch. In this mode, traffic is sent directly to the ASA FirePOWER
module without ASA processing. The traffic is “black holed,” in that nothing is returned from the module,
nor does the ASA send the traffic out any interface. You must operate the ASA in single context
transparent mode to configure traffic forwarding.
Be sure to configure consistent policies on the ASA and the ASA FirePOWER. Both policies should reflect
the inline or monitor-only mode of the traffic.
The following sections explain these modes in more detail.
ASA FirePOWER Inline Mode

In inline mode, traffic goes through the firewall checks before being forwarded to the ASA FirePOWER
module. When you identify traffic for ASA FirePOWER inspection on the ASA, traffic flows through the
ASA and the module as follows:
1 Traffic enters the ASA.
2 Incoming VPN traffic is decrypted.
3 Firewall policies are applied.
4 Traffic is sent to the ASA FirePOWER module.
5 The ASA FirePOWER module applies its security policy to the traffic, and takes appropriate actions.
6 Valid traffic is sent back to the ASA; the ASA FirePOWER module might block some traffic according
to its security policy, and that traffic is not passed on.
7 Outgoing VPN traffic is encrypted.
8 Traffic exits the ASA.
96
The following figure shows the traffic flow when using the ASA FirePOWER module in inline mode. In this
example, the module blocks traffic that is not allowed for a certain application. All other traffic is forwarded
through the ASA.
Figure 13: ASA FirePOWER Module Traffic Flow in the ASA
Note If you have a connection between hosts on two ASA interfaces, and the ASA FirePOWER service policy
is only configured for one of the interfaces, then all traffic between these hosts is sent to the ASA
FirePOWER module, including traffic originating on the non-ASA FirePOWER interface (because the
feature is bidirectional).
ASA FirePOWER Inline Tap Monitor-Only Mode

This mode sends a duplicate stream of traffic to the ASA FirePOWER module for monitoring purposes only.
The module applies the security policy to the traffic and lets you know what it would have done if it were
operating in inline mode; for example, traffic might be marked “would have dropped” in events. You can use
this information for traffic analysis and to help you decide if inline mode is desirable.
Note You cannot configure both inline tap monitor-only mode and normal inline mode at the same time on the
ASA. Only one type of security policy is allowed. In multiple context mode, you cannot configure inline
tap monitor-only mode for some contexts, and regular inline mode for others.
97
The following figure shows the traffic flow when operating in inline tap mode.
Figure 14: ASA FirePOWER Inline Tap Monitor-Only Mode
ASA FirePOWER Passive Monitor-Only Traffic Forwarding Mode

If you want to operate the ASA FirePOWER module as a pure Intrusion Detection System (IDS), where there
is no impact on the traffic at all, you can configure a traffic forwarding interface. A traffic forwarding interface
sends all received traffic directly to the ASA FirePOWER module without any ASA processing.
The module applies the security policy to the traffic and lets you know what it would have done if it were
operating in inline mode; for example, traffic might be marked “would have dropped” in events. You can use
this information for traffic analysis and to help you decide if inline mode is desirable.
Traffic in this setup is never forwarded: neither the module nor the ASA sends the traffic on to its ultimate
destination. You must operate the ASA in single context and transparent modes to use this configuration.
The following figure shows an interface configured for traffic-forwarding. That interface is connected to a
switch SPAN port so the ASA FirePOWER module can inspect all of the network traffic. Another interface
sends traffic normally through the firewall.
Figure 15: ASA FirePOWER Passive Monitor-Only, Traffic-Forwarding Mode
98
Licensing Requirements for the ASA FirePOWER Module
ASA FirePOWER Management

The module has a basic command line interface (CLI) for initial configuration and troubleshooting only. You
configure the security policy on the ASA FirePOWER module using one of the following methods:
• Firepower/FireSIGHT Management Center—Can be hosted on a separate Management Center appliance
or as a virtual appliance. The Management Center application is called Firepower beginning in version
6.0. Previous versions are called FireSIGHT.
• ASDM (check for compatibility with your model/version)—You can manage both the ASA and the
module using the on-box ASDM.
Compatibility with ASA Features

The ASA includes many advanced application inspection features, including HTTP inspection. However, the
ASA FirePOWER module provides more advanced HTTP inspection than the ASA provides, as well as
additional features for other applications, including monitoring and controlling application usage.
You must follow these configuration restrictions on the ASA:
• Do not configure ASA inspection on HTTP traffic that you send to the ASA FirePOWER module.
• Do not configure Cloud Web Security (ScanSafe) inspection on traffic that you send to the ASA
FirePOWER module. If traffic matches both your Cloud Web Security and ASA FirePOWER service
policies, the traffic is forwarded to the ASA FirePOWER module only. If you want to implement both
services, ensure there is no overlap between the traffic matching criteria for each service.
• Do not enable the Mobile User Security (MUS) server; it is not compatible with the ASA FirePOWER
module.
Other application inspections on the ASA are compatible with the ASA FirePOWER module, including the
default inspections.
Licensing Requirements for the ASA FirePOWER Module

Certain areas of ASA FirePOWER module functionality may require additional licenses.
For an ASA FirePOWER module managed by a Firepower/FireSIGHT Management Center, enable licenses
on the module using the Management Center. See the licensing chapter of the FireSIGHT System User Guide
5.4, Firepower Management Center Configuration Guide 6.0, or the online help on the FireSIGHT Management
Center for more information.
For the ASA FirePOWER module managed using ASDM, enable licenses on the module using the FirePOWER
module configuration in ASDM. See the licensing chapter of the ASA FirePOWER Module User Guide 5.4,
ASA FirePOWER Services Local Management Configuration Guide 6.0, or the online help for the module in
ASDM for more information.
The ASA itself does not require any additional licenses.
99
Guidelines for ASA FirePOWER
Guidelines for ASA FirePOWER

Failover Guidelines
Does not support failover directly; when the ASA fails over, any existing ASA FirePOWER flows are
transferred to the new ASA. The ASA FirePOWER module in the new ASA begins inspecting the traffic from
that point forward; old inspection states are not transferred.
You are responsible for maintaining consistent policies on the ASA FirePOWER modules in the high-availability
ASA pair to ensure consistent failover behavior.
ASA Clustering Guidelines

Does not support clustering directly, but you can use these modules in a cluster. You are responsible for
maintaining consistent policies on the ASA FirePOWER modules in the cluster.
Model Guidelines
• For ASA model software and hardware compatibility with the ASA FirePOWER module, see the Cisco
ASA Compatibility.
• For the 5512-X through ASA 5555-X, you must install a Cisco solid state drive (SSD). For more
information, see the ASA 5500-X hardware guide. (The SSD is standard on the 5506-X, 5508-X, and
5516-X.)
ASDM Guidelines for Managing ASA FirePOWER

• The ASA, ASDM, and ASA FirePOWER versions supported for ASDM management differ by model.
For supported combinations, see Cisco ASA Compatibility.
• If you enable command authorization on the ASA that hosts the module, you must log in with a user
name that has privilege level 15 to see the ASA FirePOWER home, configuration, and monitoring
pages. Read-only or monitor-only access to ASA FirePOWER pages other than the status page is not
supported.
• If you are using Java 7 update 51 up to Java 8, you need to configure identity certificates for both the
ASA and the ASA FirePOWER module. See Install an Identity Certificate for ASDM.
• You can never use both ASDM and Firepower/FireSIGHT Management Center, you must choose one
or the other.

• See Compatibility with ASA Features, on page 99.
• You cannot change the software type installed on the hardware module; if you purchase an ASA
FirePOWER module, you cannot later install other software on it.
• You cannot configure both normal inline mode and inline tap monitor-only mode at the same time on
the ASA. Only one type of security policy is allowed. In multiple context mode, you cannot configure
inline tap monitor-only mode for some contexts, and regular inline mode for others.
100
Defaults for ASA FirePOWER
Defaults for ASA FirePOWER

The following table lists the default settings for the ASA FirePOWER module.
Table 8: ASA FirePOWER Default Network Parameters
Parameters Default
Management IP address System software image: 192.168.45.45/24
Boot image: 192.168.8.8/24
Gateway System software image: none

Boot image: 192.168.8.1/24
SSH or session Username admin
Password System software image:

• Release 6.0 and following: Admin123
• Releases prior to 6.0: Sourcefire
Boot image: Admin123
Perform Initial ASA FirePOWER Setup

Deploy the ASA FirePOWER module in your network, and then choose your management method.
Deploy the ASA FirePOWER Module in Your Network

See the section for your firewall mode and ASA model to determine how to connect the ASA FirePOWER
module management interface to your network.
Routed Mode
ASA 5585-X (Hardware Module) in Routed Mode

The ASA FirePOWER module includes separate management interfaces from the ASA.
101
All management traffic to and from the ASA FirePOWER module must enter and exit the Management 1/0
or 1/1 interface. The ASA FirePOWER module also needs Internet access. Because the Management 1/x
interface is not an ASA data interface, traffic cannot pass through the ASA over the backplane; therefore you
need to physically cable the management interface to an ASA interface. See the following typical cabling
setup to allow ASA FirePOWER access to the Internet through the ASA management interface (or you could
use a data interface). Other options are possible, depending on how you want to connect your network; for
example, you can make the Management 1/0 interface outside facing; or you can route between it and a
different ASA interface if you have an inside router.
ASA 5506-X through ASA 5555-X (Software Module) in Routed Mode

These models run the ASA FirePOWER module as a software module, and the ASA FirePOWER module
shares the Management 0/0 or Management 1/1 interface (depending on your model) with the ASA.
All management traffic to and from the ASA FirePOWER module must enter and exit the Management
interface. The ASA FirePOWER module also needs Internet access. Management traffic cannot pass through
the ASA over the backplane; therefore you need to physically cable the management interface to an ASA
interface to reach the Internet.
If you do not configure a name and IP address in the ASA configuration for Management, then the interface
belongs exclusively to the module. In this case, the Management interface is not a regular ASA interface, and
you can:
1 Configure the ASA FirePOWER IP address to be on the same network as a regular ASA data interface.
2 Specify the data interface as the ASA FirePOWER gateway.
3 Directly connect the Management interface to the data interface (using a Layer2 switch).
102
See the following typical cabling setup to allow ASA FirePOWER access to the Internet through the ASA
inside interface.
For the ASA 5506-X, 5508-X, and 5516-X, the default configuration enables the above network deployment;
the only change you need to make is to set the module IP address to be on the same network as the ASA inside
interface and to configure the module gateway IP address.
For other models, you must remove the ASA-configured name and IP address for Management 0/0 or 1/1,
and then configure the other interfaces as indicated above.
Note If you want to deploy a separate router on the inside network, then you can route between management
and inside. In this case, you can manage both the ASA and ASA FirePOWER module on the Management
interface with the appropriate configuration changes, including configuring the ASA name and IP address
for the Management interface (on the same network as the ASA FirePOWER module address).
Transparent Mode
ASA 5585-X (Hardware Module) in Transparent Mode

The ASA FirePOWER module includes separate management interfaces from the ASA.
103
All management traffic to and from the ASA FirePOWER module must enter and exit the Management 1/0
or 1/1 interface. The ASA FirePOWER module also needs Internet access. Because this interface is not an
ASA data interface, traffic cannot pass through the ASA over the backplane; therefore you need to physically
cable the management interface to an ASA interface. See the following typical cabling setup to allow ASA
FirePOWER access to the Internet through the ASA inside interface.
ASA 5506-X through ASA 5555-X, ISA 3000 (Software Module) in Transparent Mode
These models run the ASA FirePOWER module as a software module, and the ASA FirePOWER module
shares the Management 0/0 or Management 1/1 interface (depending on your model) with the ASA.
All management traffic to and from the ASA FirePOWER module must enter and exit the Management
interface. The ASA FirePOWER module also needs Internet access.
The following figure shows the recommended network deployment for the ASA 5500-X or ISA 3000 with
the ASA FirePOWER module:
Register the ASA FirePOWER Module with a Management Center

To register the module with a Firepower/FireSIGHT Management Center, you must access the ASA
FirePOWER module CLI. The first time you access the CLI, you are prompted for basic configuration
parameters. You must also add the module to the Management Center.
104
Note If you want to use ASDM to manage the module, skip this section and see Configure the ASA FirePOWER
Module for ASDM Management, on page 107.
Access the ASA FirePOWER CLI

To access the ASA FirePOWER CLI, you can use one of the following methods.
Procedure
Step 1 Console Port:

• ASA 5585-X—This model includes a dedicated console port for the ASA FirePOWER module. Use
the supplied DB-9 to RJ-45 serial cable and/or your own USB serial adapter.
• All other models—Connect to the ASA console port using the supplied DB-9 to RJ-45 serial cable and/or
your own USB serial adapter. The ASA 5506-X/5508-X/5516-X also has a mini-USB console port. See
the hardware guide for instructions on using the USB console port.
At the ASA CLI, session to the ASA FirePOWER module:
session sfr
See also Session to the Software Module From the ASA.
Step 2 SSH:
You can connect to the module default IP address (see Defaults for ASA FirePOWER, on page 101) or you
can use ASDM on the ASA to change the management IP address, and then connect using SSH:
In ASDM, choose Wizards > Startup Wizard, and progress through the wizard to the ASA FirePOWER
Basic Configuration, where you can set the IP address, mask, and default gateway.
Configure ASA FirePOWER Basic Settings

The first time you access the ASA FirePOWER module CLI, you are prompted for basic configuration
parameters. You must also add the module to the Firepower/FireSIGHT Management Center if you are not
using ASDM.
Before You Begin

Access the module CLI according to Access the ASA FirePOWER CLI, on page 105.
Procedure
Step 1 At the ASA FirePOWER CLI, log in with the username admin.
If this is the first time you are logging in, use the default password. See Defaults for ASA FirePOWER, on
page 101.
Step 2 Complete the system configuration as prompted.
105
Use the following network settings for the ASA FirePOWER module for the recommended network deployment
(Deploy the ASA FirePOWER Module in Your Network, on page 101):
• Management interface: 192.168.1.2
• Management subnet mask: 255.255.255.0
• Gateway IP: 192.168.1.1
Example:
System initialization in progress. Please stand by.
You must change the password for 'admin' to continue.
Enter new password: <new password>
Confirm new password: <repeat password>
You must configure the network to continue.
You must configure at least one of IPv4 or IPv6.
Do you want to configure IPv4? (y/n) [y]: y
Do you want to configure IPv6? (y/n) [n]:
Configure IPv4 via DHCP or manually? (dhcp/manual) [manual]:
Enter an IPv4 address for the management interface [192.168.45.45]: 10.86.118.3
Enter an IPv4 netmask for the management interface [255.255.255.0]: 255.255.252.0
Enter the IPv4 default gateway for the management interface []: 10.86.116.1
Enter a fully qualified hostname for this system [Sourcefire3D]: asasfr.example.com
Enter a comma-separated list of DNS servers or 'none' []: 10.100.10.15,
10.120.10.14
Enter a comma-separated list of search domains or 'none' [example.net]: example.com
If your networking information has changed, you will need to reconnect.
For HTTP Proxy configuration, run 'configure network http-proxy'
(Wait for the system to reconfigure itself.)
This sensor must be managed by a Defense Center. A unique alphanumeric

registration key is always required. In most cases, to register a sensor
to a Defense Center, you must provide the hostname or the IP address along
with the registration key.
'configure manager add [hostname | ip address ] [registration key ]'
However, if the sensor and the Defense Center are separated by a NAT device,
you must enter a unique NAT ID, along with the unique registration key.
'configure manager add DONTRESOLVE [registration key ] [ NAT ID ]'
Later, using the web interface on the Defense Center, you must use the same
registration key and, if necessary, the same NAT ID when you add this
sensor to the Defense Center.
Step 3 Register the ASA FirePOWER module to a Management Center:

> configure manager add {hostname | IPv4_address | IPv6_address | DONTRESOLVE} reg_key [nat_id]
where:
• {hostname | IPv4_address | IPv6_address | DONTRESOLVE} specifies either the fully qualified host
name or IP address of the Management Center. If the Management Center is not directly addressable,
use DONTRESOLVE.
• reg_key is the unique alphanumeric registration key required to register a ASA FirePOWER module to
the Management Center.
• nat_id is an optional alphanumeric string used during the registration process between the Management
Center and the ASA FirePOWER module. It is required if the hostname is set to DONTRESOLVE.
Step 4 Close the console connection. For the software module, enter:
> exit
106
Configure the ASA FirePOWER Module for ASDM Management

Not supported for all version/model combinations; check for compatibility with your model and version.
ASDM can change the ASA FirePOWER module IP address over the ASA backplane, but all further
management requires network access between the ASDM interface and the Management interface, where the
module is reachable.
To use ASDM to manage the module, launch ASDM and run the Startup Wizard.
Procedure
Step 1 On the computer connected to the ASA, launch a web browser.

Step 2 In the Address field, enter the following URL: https://192.168.1.1/admin. The Cisco ASDM web page
appears.
Step 3 Click one of the available options: Install ASDM Launcher, Run ASDM, or Run Startup Wizard.
Step 4 Follow the onscreen instructions to launch ASDM according to the option you chose. The Cisco ASDM-IDM
Launcher appears.
Note If you click Install ASDM Launcher, in some cases you need to install an identity certificate for the
ASA and a separate certificate for the ASA FirePOWER module according to Install an Identity
Certificate for ASDM.
Step 5 Leave the username and password fields empty, and click OK. The main ASDM window appears.
Step 6 If you are prompted to provide the IP address of the installed ASA Firepower module, cancel out of the dialog
box. You must first set the module IP address to the correct IP address using the Startup Wizard.
Step 7 Choose Wizards > Startup Wizard.
Step 8 Configure additional ASA settings as desired, or skip screens until you reach the ASA Firepower Basic
Configuration screen.
107
Set the following values to work with the default configuration:

• IP Address—192.168.1.2
• Subnet Mask—255.255.255.0
• Gateway—192.168.1.1
108
Configure the ASA FirePOWER Module
Step 9 Click I accept the agreement, and click Next or Finish to complete the wizard.
Step 10 Quit ASDM, and then relaunch. You should see ASA Firepower tabs on the Home page.

Configure the security policy in the ASA FirePOWER module, and then configure the ASA to send traffic to
the module.
Configure the Security Policy on the ASA FirePOWER Module

The security policy controls the services provided by the module, such as Next Generation IPS filtering and
application filtering. You configure the security policy on the ASA FirePOWER module using one of the
following methods.
FireSIGHT Management Center

Use a web browser to open https://DC_address, where DC_address is the DNS name or IP address of the
manager you defined in Configure ASA FirePOWER Basic Settings, on page 105. For example,
https://dc.example.com.
Alternatively, in ASDM, choose Home > ASA FirePOWER Status and click the link at the bottom of the
dashboard.
For more information about ASA FirePOWER configuration, see the Management Center online help,
FireSIGHT System User Guide 5.4, or Firepower Management Center Configuration Guide 6.0 (available at
http://www.cisco.com/c/en/us/support/security/defense-center/
products-installation-and-configuration-guides-list.html).
ASDM
In ASDM, choose Configuration > ASA FirePOWER Configuration.
For more information about ASA FirePOWER configuration, see the module's online help in ASDM, ASA
FirePOWER Module User Guide 5.4, or ASA FirePOWER Services Local Management Configuration Guide
6.0 (available at http://www.cisco.com/c/en/us/support/security/asa-firepower-services/
products-installation-and-configuration-guides-list.html.
Redirect Traffic to the ASA FirePOWER Module

For inline and inline tap (monitor-only) modes, you configure a service policy to redirect traffic to the module.
If you want passive monitor-only mode, you configure a traffic redirection interface, which bypasses ASA
policies.
The following topics explain how to configure these modes.
Configure Inline or Inline Tap Monitor-Only Modes

Redirect traffic to the ASA FirePOWER module by creating a service policy that identifies specific traffic
that you want to send. In this mode, ASA policies, such as access rules, are applied to the traffic before it is
redirected to the module.
109
Before You Begin

• If you have an active service policy redirecting traffic to an IPS or CX module (that you replaced with
ASA FirePOWER), you must remove that policy before you configure the ASA FirePOWER service
policy.
• Be sure to configure consistent policies on the ASA and the ASA FirePOWER. Both policies should
reflect the inline or inline tap mode of the traffic.
• In multiple context mode, perform this procedure within each security context.
Procedure
Step 1 Choose Configuration > Firewall > Service Policy Rules.

Step 2 Choose Add > Add Service Policy Rule.
Step 3 Choose whether to apply the policy to a particular interface or apply it globally and click Next.
Step 4 Configure the traffic match. For example, you could match Any Traffic so that all traffic that passes your
inbound access rules is redirected to the module. Or, you could define stricter criteria based on ports, ACL
(source and destination criteria), or an existing traffic class. The other options are less useful for this policy.
After you complete the traffic class definition, click Next.
Step 5 On the Rule Actions page, click the ASA FirePOWER Inspection tab.
Step 6 Check the Enable ASA FirePOWER for this traffic flow check box.
Step 7 In the If ASA FirePOWER Card Fails area, click one of the following:
• Permit traffic—Sets the ASA to allow all traffic through, uninspected, if the module is unavailable.
• Close traffic—Sets the ASA to block all traffic if the module is unavailable.
Step 8 (Optional) Check Monitor-only to send a read-only copy of traffic to the module (inline tap mode).
By default, the traffic is sent in inline mode. Be sure to configure consistent policies on the ASA and the ASA
FirePOWER. Both policies should reflect the inline or monitor-only of the traffic.
Step 9 Click Finish and then Apply.

Repeat this procedure to configure additional traffic flows as desired.
Configure Passive Traffic Forwarding

If you want to operate the module in passive monitor-only mode, where the module gets a copy of the traffic
and neither it nor the ASA can affect the network, configure a traffic forwarding interface and connect the
interface to a SPAN port on a switch. For more details, see ASA FirePOWER Passive Monitor-Only Traffic
Forwarding Mode, on page 98.
The following guidelines explain the requirements for this deployment mode:
• The ASA must be in single-context and transparent mode.
• You can configure up to 4 interfaces as traffic-forwarding interfaces. Other ASA interfaces can be used
as normal.
110
• Traffic-forwarding interfaces must be physical interfaces, not VLANs or BVIs. The physical interface
also cannot have any VLANs associated with it.
• Traffic-forwarding interfaces cannot be used for ASA traffic; you cannot name them or configure them
for ASA features, including failover or management-only.
• You cannot configure both a traffic-forwarding interface and a service policy for ASA FirePOWER
traffic.
Procedure
Step 1 Enter interface configuration mode for the physical interface you want to use for traffic-forwarding.
interface physical_interface
Example:
hostname(config)# interface gigabitethernet 0/5
Step 2 Remove any name configured for the interface. If this interface was used in any ASA configuration, that
configuration is removed. You cannot configure traffic-forwarding on a named interface.
no nameif
Step 3 Enable traffic-forwarding.

traffic-forward sfr monitor-only
Note You can ignore any warnings about traffic forwarding being for demonstration purposes only. This
is a supported production mode.
Step 4 Enable the interface.
no shutdown
Repeat for any additional interfaces.
Example
The following example makes GigabitEthernet 0/5 a traffic-forwarding interface:
interface gigabitethernet 0/5

no nameif
traffic-forward sfr monitor-only
no shutdown
Enable Captive Portal for Active Authentication

ASA FirePOWER includes identity policies that allow you to collect user identification information. By
collecting user identity information, you can tailor access control rules to specific users and user groups,
selectively allowing and disallowing access based on the user. You can also analyze traffic based on user
identity.
For HTTP/HTTPS connections, you can define identity rules that collect user identification through active
authentication. If you want to implement active authentication identity rules, you must enable captive portal
on the ASA to act as the authentication proxy port. When a connection matches an identity rule that requests
111
Managing the ASA FirePOWER Module
active authentication, the ASA FirePOWER module redirects the authentication request to the ASA interface
IP address/captive portal. The default port is 885, which you can change.
If you do not enable captive portal for the authentication proxy, only passive authentication is available.
Before You Begin

• This feature is available in routed mode only for ASA FirePOWER 6.0+ only.
• In multiple context mode, perform this procedure within each security context.
Procedure
Step 1 Select Tools > Command Line Tool.

Step 2 Enable captive portal.
captive-portal {global | interface name} [port number]
Where:
• global enables captive portal globally on all interfaces.
• interface name enables captive portal on the specified interface only. You can enter the command
multiple times to enable it on more than one interface. You can use this approach if you are redirecting
traffic for only a subset of interfaces to the ASA FirePOWER module.
• port number optionally specifies the authentication port. If you do not include the keyword, port 885 is
used. If you do include the keyword, the port number must be 1025 or higher.
Example:
For example, to enable captive portal globally on port 885, enter the following:
ciscoasa(config)# captive-portal global

ciscoasa(config)#
Step 3 In the ASA FirePOWER identity policy, ensure that the active authentication settings specify the same port
you configured for captive portal, and configure the other required settings to enable active authentication.

This section includes procedures that help you manage the module.
Install or Reimage the Module

This section describes how to install or reimage a software or hardware module.
Install or Reimage the Software Module

If you purchase the ASA with the ASA FirePOWER module, the module software and required solid state
drives (SSDs) come pre-installed and ready to configure. If you want to add the ASA FirePOWER software
112
module to an existing ASA, or need to replace the SSD, you need to install the ASA FirePOWER boot software,
partition the SSD, and install the system software according to this procedure.
Reimaging the module is the same procedure, except you should first uninstall the ASA FirePOWER module.
You would reimage a system if you replace an SSD.
For information on how to physically install the SSD, see the ASA hardware guide.
Before You Begin

• The free space on flash (disk0) should be at least 3GB plus the size of the boot software.
• In multiple context mode, perform this procedure in the system execution space.
• You must shut down any other software module that you might be running; the ASA can run a single
software module at a time. You must do this from the ASA CLI. For example, the following commands
shut down and uninstall the IPS software module, and then reload the ASA; the commands to remove
the CX module are the same, except use the cxsc keyword instead of ips.
sw-module module ips shutdown sw-module module ips uninstall reload
When reimaging the ASA FirePOWER module, use the same shutdown and uninstall commands to
remove the old image. For example, sw-module module sfr uninstall.
• If you have an active service policy redirecting traffic to an IPS or CX module, you must remove that
policy. For example, if the policy is a global one, you could use no service-policy ips_policy global. If
the service policy includes other rules you want to maintain, simply remove the redirection command
from the relevant policy map, or the entire traffic class if redirection is the only action for the class. You
can remove the policies using CLI or ASDM.
• Obtain both the ASA FirePOWER Boot Image and System Software packages from Cisco.com.
Procedure
Step 1 Download the boot image to the ASA. Do not transfer the system software; it is downloaded later to the SSD.
You have the following options:
• ASDM—First, download the boot image to your workstation, or place it on an FTP, TFTP, HTTP,
HTTPS, SMB, or SCP server. Then, in ASDM, choose Tools > File Management, and then choose the
appropriate File Transfer command, either Between Local PC and Flash or Between Remote Server
and Flash. Transfer the boot software to disk0 on the ASA.
• ASA CLI—First, place the boot image on a TFTP, FTP, HTTP, or HTTPS server, then use the copy
command to download it to flash. The following example uses TFTP.
ciscoasa# copy tftp://10.1.1.89/asasfr-5500x-boot-5.4.1-58.img

disk0:/asasfr-5500x-boot-5.4.1-58.img
Step 2 Download the ASA FirePOWER system software from Cisco.com to an HTTP, HTTPS, or FTP server
accessible from the ASA FirePOWER management interface. Do not download it to disk0 on the ASA.
Step 3 Set the ASA FirePOWER module boot image location in ASA disk0 by entering the following command:
sw-module module sfr recover configure image disk0: file_path
113
Example:
hostname# sw-module module sfr recover configure image disk0:asasfr-5500x-boot-5.4.1-58.img
If you see a message like “ERROR: Another service (cxsc) is running, only one service is allowed to run at
any time,” it means that you already have a different software module configured. You must shut it down and
remove it to install a new module as described in the prerequisites section above.
Step 4 Load the ASA FirePOWER boot image:

sw-module module sfr recover boot
Step 5 Wait approximately 5-15 minutes for the ASA FirePOWER module to boot up, and then open a console
session to the now-running ASA FirePOWER boot image. You might need to press enter after opening the
session to get to the login prompt. The default username is admin and the default password is Admin123.
hostname# session sfr console

Opening console session with module sfr.
Connected to module sfr. Escape character sequence is 'CTRL-^X'.
Cisco ASA SFR Boot Image 5.3.1

asasfr login: admin
Password: Admin123
If the module boot has not completed, the session command will fail with a message about not being able to
connect over ttyS1. Wait and try again.
Step 6 Configure the system so that you can install the system software package:
asasfr-boot> setup
Example:
asasfr-boot> setup
Welcome to SFR Setup

[hit Ctrl-C to abort]
Default values are inside []
You are prompted for the following. Note that the management address and gateway, and DNS information,
are the key settings to configure.
• Host name—Up to 65 alphanumeric characters, no spaces. Hyphens are allowed.
• Network address—You can set static IPv4 or IPv6 addresses, or use DHCP (for IPv4) or IPv6 stateless
autoconfiguration.
• DNS information—You must identify at least one DNS server, and you can also set the domain name
and search domain.
• NTP information—You can enable NTP and configure the NTP servers, for setting system time.
Step 7 Install the System Software image:

asasfr-boot> system install [noconfirm] url
114
Include the noconfirm option if you do not want to respond to confirmation messages. Use an HTTP, HTTPS,
or FTP URL; if a username and password are required, you will be prompted to supply them.
When installation is complete, the system reboots. The time required for application component installation
and for the ASA FirePOWER services to start differs substantially: high-end platforms can take 10 or more
minutes, but low-end platforms can take 60-80 minutes or longer. (The show module sfr output should show
all processes as Up.)
For example:
asasfr-boot> system install http://upgrades.example.com/packages/asasfr-sys-5.4.1-58.pkg

Verifying
Downloading
Extracting
Package Detail
Description: Cisco ASA-FirePOWER 5.4.1-58 System Install
Requires reboot: Yes
Do you want to continue with upgrade? [y]: y

Warning: Please do not interrupt the process or turn off the system.
Doing so might leave system in unusable state.
Upgrading
Starting upgrade process ...
Populating new system image
Reboot is required to complete the upgrade. Press 'Enter' to reboot the system.
(press Enter)
Broadcast message from root (ttyS1) (Mon Feb 17 19:28:38 2014):
The system is going down for reboot NOW!

Console session with module sfr terminated.
Step 8 Open a session to the ASA FirePOWER module. You will see a different login prompt because you are logging
into the fully functional module.
ciscoasa# session sfr console
Example:
ciscoasa# session sfr console
Opening console session with module sfr.
Connected to module sfr. Escape character sequence is 'CTRL-^X'.
Sourcefire ASA5555 v5.4.1 (build 58)

Sourcefire3D login:
Step 9 See Configure ASA FirePOWER Basic Settings, on page 105 to complete the setup.
Reimage the 5585-X ASA FirePOWER Hardware Module

If you need to reimage the ASA FirePOWER hardware module in an ASA 5585-X for any reason, you need
to install both the Boot Image and a System Software package, in that order. You must install both packages
115
to have a functioning system. Under normal circumstances, you do not need to reimage the system to install
upgrade packages.
To install the boot image, you need to TFTP boot the image from the Management-0 port on the ASA
FirePOWER SSP by logging into the module’s Console port. Because the Management-0 port is on an SSP
in the first slot, it is also known as Management1/0, but ROMMON recognizes it as Management-0 or
Management0/1.
Before You Begin

To accomplish a TFTP boot, you must:
• Place the Boot Image and a System Software package on a TFTP server that can be accessed through
the Management1/0 interface on the ASA FirePOWER module.
• Connect Management1/0 to the network. You must use this interface to TFTP boot the Boot Image.
Procedure
Step 1 Connect to the module console port.

Step 2 Reload the system:
system reboot
Step 3 When prompted, break out of the boot by pressing Esc. If you see grub start to boot the system, you have
waited too long.
This will place you at the ROMMON prompt.
Step 4 At the ROMMON prompt, enter:

set
Configure the following parameters:
• ADDRESS—The management IP address of the module.
• SERVER—The IP address of the TFTP server.
• GATEWAY—The gateway address to the TFTP server. If the TFTP server is directly attached to
Management1/0, use the IP address of the TFTP server. If the TFTP server and management address
are on the same subnet, do not configure the gateway or TFTP boot will fail.
• IMAGE—The Boot Image path and image name on the TFTP server. For example, if you place the file
on the TFTP server in /tftpboot/images/filename.img, the IMAGE value is images/filename.img.
Example:
ADDRESS=10.5.190.199
SERVER=10.5.11.170
GATEWAY=10.5.1.1
IMAGE=asasfrboot-5.4.1-58.img
Step 5 Save the settings:

sync
Step 6 Initiate the download and boot process:

tftp
116
You will see ! marks to indicate progress. When the boot completes after several minutes, you will see a login
prompt.
Step 7 Log in as admin, with the password Admin123.

Step 8 Configure the system so that you can install the system software package:
setup
You are prompted for the following. Note that the management address and gateway, and DNS information,
are the key settings to configure.
• Host name—Up to 65 alphanumeric characters, no spaces. Hyphens are allowed.
• Network address—You can set static IPv4 or IPv6 addresses, or use DHCP (for IPv4) or IPv6 stateless
autoconfiguration.
• DNS information—You must identify at least one DNS server, and you can also set the domain name
and search domain.
• NTP information—You can enable NTP and configure the NTP servers, for setting system time.
Step 9 Install the System Software image:

system install [noconfirm] url
Example:
asasfr-boot> system install http://upgrades.example.com/packages/asasfr-sys-5.4.1-58.pkg
Include the noconfirm option if you do not want to respond to confirmation messages.
When installation is complete, the system reboots. Allow 10 or more minutes for application component
installation and for the ASA FirePOWER services to start.
Step 10 When the boot completes, log in as admin with the defautl password. See Defaults for ASA FirePOWER,
on page 101.
Step 11 See Configure ASA FirePOWER Basic Settings, on page 105 to complete the setup.
Reset the Password

If you forget the password for the admin user, another user with CLI Configuration permissions can log in
and change the password.
If there are no other users with the required permissions, you can reset the admin password from the ASA.
The default password differs based on software release; see Defaults for ASA FirePOWER, on page 101.
Before You Begin

• The password-reset option on the ASA hw-module and sw-module commands does not work with ASA
FirePOWER.
117
Procedure
Reset the module password for the user admin to the default:
session {1 | sfr} do password-reset
Use 1 for a hardware module, sfr for a software module.
Reload or Reset the Module

You can reload, or to reset and then reload, the module from the ASA.
Before You Begin

In multiple context mode, perform this procedure in the system execution space.
Procedure
Enter one of the following commands:

• Hardware module (ASA 5585-X):
hw-module module 1 {reload | reset}
• Software module (all other models):
sw-module module sfr {reload | reset}
Shut Down the Module

Shutting down the module software prepares the module to be safely powered off without losing configuration
data.
Before You Begin

• If you reload the ASA, the module is not automatically shut down, so we recommend shutting down the
module before reloading the ASA.
Procedure
Enter one of the following commands:

• Hardware module (ASA 5585-X):
hw-module module 1 shutdown
• Software module (all other models):
sw-module module sfr shutdown
118
Uninstall a Software Module Image

You can uninstall a software module image and its associated configuration.
Before You Begin

In multiple context mode, perform this procedure in the system execution space.
Procedure
Step 1 Uninstall the software module image and associated configuration.

sw-module module sfr uninstall
Example:
ciscoasa# sw-module module sfr uninstall
Module sfr will be uninstalled. This will completely remove the disk image
associated with the sw-module including any configuration that existed within it.
Uninstall module sfr? [confirm]
Step 2 Reload the ASA.

reload
You must reload the ASA before you can install a new module.
Session to the Software Module From the ASA

Use the ASA FirePOWER CLI to configure basic network settings and to troubleshoot the module.
To access the ASA FirePOWER software module CLI from the ASA, you can session from the ASA. (You
cannot session to a hardware module running on a 5585-X.)
You can either session to the module (using Telnet) or create a virtual console session. A console session
might be useful if the control plane is down and you cannot establish a Telnet session. In multiple context
mode, session from the system execution space.
In either a Telnet or a Console session, you are prompted for a username and password. You can log in with
any username configured on the ASA FirePOWER. Initially, the admin username is the only one configured
(and it is always available). The initial default password differs based on the type of image (full image or boot
image) and software release; see Defaults for ASA FirePOWER, on page 101.
• Telnet session:
session sfr
When in the ASA FirePOWER CLI, to exit back to the ASA CLI, enter any command that would log
you out of the module, such as logout or exit, or press Ctrl-Shift-6, x.
• Console session:
session sfr console
119
Monitoring the ASA FirePOWER Module
The only way out of a console session is to press Ctrl-Shift-6, x. Logging out of the module leaves you
at the module login prompt.
Note Do not use the session sfr console command in conjunction with a terminal server where Ctrl-Shift-6, x
is the escape sequence to return to the terminal server prompt. Ctrl-Shift-6, x is also the sequence to
escape the ASA FirePOWER console and return to the ASA prompt. Therefore, if you try to exit the ASA
FirePOWER console in this situation, you instead exit all the way to the terminal server prompt. If you
reconnect the terminal server to the ASA, the ASA FirePOWER console session is still active; you can
never exit to the ASA prompt. You must use a direct serial connection to return the console to the ASA
prompt. Use the session sfr command instead of the console command when facing this situation.
Upgrade the System Software

Before applying an upgrade, ensure that the ASA is running the minimum required release for the new version;
you might need to upgrade the ASA prior to upgrading the module. For more information about applying
upgrades, see the Management Center online help, FireSIGHT System User Guide 5.4, or Firepower
Management Center Configuration Guide 6.0.
For ASDM management, you can apply upgrades to the system software and components using Configuration
> ASA FirePOWER Configuration > Updates. Click Help on the Updates page for more information.

The following topics provide guidance on monitoring the module. For ASA FirePOWER-related syslog
messages, see the syslog messages guide. ASA FirePOWER syslog messages start with message number
434001.
Use Tools > Command Line Interface to use monitoring commands.
Showing Module Status

From the Home page, you can select the ASA FirePOWER Status tab to view information about the module.
This includes module information, such as the model, serial number, and software version, and module status,
such as the application name and status, data plane status, and overall status. If the module is registered to a
Management Center, you can click the link to open the application and do further analysis and module
configuration.
When managing the module with ASDM, you can also use the Home > ASA FirePOWER Dashboard page
to view summary information about the software running on the module, product updates, licensing, system
load, disk usage, system time, and interface status.
Showing Module Statistics

Use the show service-policy sfr command to display statistics and status for each service policy that includes
the sfr command. Use clear service-policy to clear the counters.
120
The following example shows the ASA FirePOWER service policy and the current statistics as well as the
module status. In monitor-only mode, the input counters remain at zero.
ciscoasa# show service-policy sfr
Global policy:
Service-policy: global_policy
Class-map: my-sfr-class
SFR: card status Up, mode fail-close
packet input 2626422041, packet output 2626877967, drop 0, reset-drop 0, proxied 0
Analyzing Operational Behavior (ASDM Management)

When you manage the ASA FirePOWER module using ASDM, you can view operational information for the
module using these pages:
• Home > ASA FirePOWER Reporting—The reporting page provides Top 10 dashboards for a wide
variety of module statistics, such as web categories, users, sources, and destinations for the traffic passing
through the module.
• Monitoring > ASA FirePOWER Monitoring—There are several pages for monitoring the module,
including syslog, task status, module statistics, and a real-time event viewer.
Monitoring Module Connections

To show connections through the ASA FirePOWER module, enter one of the following commands:
• show asp table classify domain sfr
Shows the NP rules created to send traffic to the ASA FirePOWER module.
• show asp drop
Shows dropped packets. The drop types are explained below.
• show conn
Shows if a connection is being forwarded to a module by displaying the ‘X - inspected by service module’
flag.
The show asp drop command can include the following drop reasons related to the ASA FirePOWER module.
Frame Drops:
• sfr-bad-tlv-received—This occurs when ASA receives a packet from FirePOWER without a Policy ID
TLV. This TLV must be present in non-control packets if it does not have the Standby/Active bit set in
the actions field.
• sfr-request—The frame was requested to be dropped by FirePOWER due a policy on FirePOWER
whereby FirePOWER would set the actions to Deny Source, Deny Destination, or Deny Pkt. If the frame
should not have been dropped, review the policies on the module that are denying the flow.
• sfr-fail-close—The packet is dropped because the card is not up and the policy configured was ‘fail-close’
(rather than ‘fail-open’ which allows packets through even if the card was down). Check card status and
attempt to restart services or reboot it.
121
History for the ASA FirePOWER Module
• sfr-fail—The FirePOWER configuration was removed for an existing flow and we are not able to process
it through FirePOWER it will be dropped. This should be very unlikely.
• sfr-malformed-packet—The packet from FirePOWER contains an invalid header. For instance, the
header length may not be correct.
• sfr-ha-request—This counter is incremented when the security appliance receives a FirePOWER HA
request packet, but could not process it and the packet is dropped.
• sfr-invalid-encap—This counter is incremented when the security appliance receives a FirePOWER
packet with invalid message header, and the packet is dropped.
• sfr-bad-handle-received—Received Bad flow handle in a packet from FirePOWER Module, thus dropping
flow. This counter is incremented, flow and packet are dropped on ASA as the handle for FirePOWER
flow has changed in flow duration.
• sfr-rx-monitor-only—This counter is incremented when the security appliance receives a FirePOWER
packet when in monitor-only mode, and the packet is dropped.
Flow Drops:
• sfr-request—The FirePOWER requested to terminate the flow. The actions bit 0 is set.
• reset-by-sfr—The FirePOWER requested to terminate and reset the flow. The actions bit 1 is set.
• sfr-fail-close—The flow was terminated because the card is down and the configured policy was
'fail-close'.

Platform
Feature Releases Description
ASA 5585-X (all models) support for the ASA 9.2(2.4) The ASA FirePOWER module supplies next-generation firewall
matching ASA FirePOWER SSP hardware services, including Next-Generation IPS (NGIPS), Application
ASA
module. Visibility and Control (AVC), URL filtering, and Advanced
FirePOWER
Malware Protection (AMP).You can use the module in single
ASA 5512-X through ASA 5555-X support for 5.3.1
or multiple context mode, and in routed or transparent mode.
the ASA FirePOWER software module.
We introduced the following screens:
Home > ASA FirePOWER Status Wizards > Startup Wizard
> ASA FirePOWER Basic Configuration Configuration >
Firewall > Service Policy Rules > Add Service Policy Rule >
Rule Actions > ASA FirePOWER Inspection
122
Platform
Feature Releases Description
ASA 5506-X support for the ASA FirePOWER ASA 9.3(2) You can run the ASA FirePOWER software module on the
software module, including support for ASA 5506-X. You can manage the module using FireSIGHT
ASDM 7.3(3)
configuring the module in ASDM Management Center, or you can use ASDM.
ASA
FirePOWER
5.4.1 Home > ASA FirePOWER Dashboard, Home > ASA
FirePOWER Reporting, Configuration > ASA FirePOWER
Configuration (including sub-pages), Monitoring > ASA
FirePOWER Monitoring (including sub-pages).
ASA FirePOWER passive monitor-only mode ASA 9.3(2) You can now configure a traffic forwarding interface to send
using traffic redirection interfaces traffic to the module instead of using a service policy. In this
ASA
mode, neither the module nor the ASA affects the traffic.
FirePOWER
5.4.1 We fully supported the following command: traffic-forward
sfr monitor-only. You can configure this in CLI only.
Support for managing the module through ASA 9.4(1) You can manage the module using ASDM instead of using
ASDM for the 5506H-X, 5506W-X, 5508-X, FireSIGHT Management Center.
ASDM 7.4(1)
and 5516-X. No new screens or commands were added.
ASA
FirePOWER
5.4.1
Support for managing the module through ASA 9.5.(1.5) You can manage the module using ASDM instead of using
ASDM for the 5512-X through 5585-X. Firepower Management Center (formerly FireSIGHT
ASDM
Management Center).
7.5(1.112)
No new screens or commands were added.
ASA
FirePOWER 6.0
Captive portal for active authentication on ASA ASA 9.5.(2) The captive portal feature is required to enable active
FirePOWER 6.0. authentication using identity policies starting with ASA
ASA
FirePOWER 6.0 FirePOWER 6.0.
We introduced or modified the following commands:
captive-portal, clear configure captive-portal, show
running-config captive-portal.
123
124
CHAPTER 8
ASA and Cisco Cloud Web Security
Cisco Cloud Web Security (also known as ScanSafe) provides web security and web filtering services through
the Software-as-a-Service (SaaS) model. Enterprises with the ASA in their network can use Cloud Web
Security services without having to install additional hardware.
• Information About Cisco Cloud Web Security, page 125

• Licensing Requirements for Cisco Cloud Web Security, page 128
• Guidelines for Cloud Web Security, page 129
• Configure Cisco Cloud Web Security, page 130
• Monitoring Cloud Web Security, page 139
• Examples for Cisco Cloud Web Security, page 140
• History for Cisco Cloud Web Security, page 145
Information About Cisco Cloud Web Security

When you enable Cloud Web Security on the ASA, the ASA transparently redirects selected HTTP and HTTPS
traffic to the Cloud Web Security proxy servers based on service policy rules. The Cloud Web Security proxy
servers then scan the content and allow, block, or send a warning about the traffic based on the policy configured
in Cisco ScanCenter to enforce acceptable use and to protect users from malware.
The ASA can optionally authenticate and identify users with Identity Firewall and AAA rules. The ASA
encrypts and includes the user credentials (including usernames and user groups) in the traffic it redirects to
Cloud Web Security. The Cloud Web Security service then uses the user credentials to match the traffic to
the policy. It also uses these credentials for user-based reporting. Without user authentication, the ASA can
supply an (optional) default username and group, although usernames and groups are not required for the
Cloud Web Security service to apply policy.
You can customize the traffic you want to send to Cloud Web Security when you create your service policy
rules. You can also configure a “whitelist” so that a subset of web traffic that matches the service policy rule
instead goes directly to the originally requested web server and is not scanned by Cloud Web Security.
You can configure a primary and a backup Cloud Web Security proxy server, each of which the ASA polls
regularly to check for availability.
125
User Identity and Cloud Web Security

You can use user identity to apply policy in Cloud Web Security. User identity is also useful for Cloud Web
Security reporting. User identity is not required to use Cloud Web Security. There are other methods to identify
traffic for Cloud Web Security policy.
You can use the following methods of determining the identity of a user or of providing a default identity:
• Identity firewall—When the ASA uses identity firewall with Active Directory (AD), the username and
group is retrieved from the AD agent. Users and groups are retrieved when you use them in an ACL in
a feature such as an access rule or in your service policy, or by configuring the user identity monitor to
download user identity information directly.
• AAA rules—When the ASA performs user authentication using a AAA rule, the username is retrieved
from the AAA server or local database. Identity from AAA rules does not include group information.
If you configure a default group, these users are associated with that default group. For information
about configuring AAA rules, see the legacy feature guide.
• Default username and group—For traffic that does not have an associated user name or group, you can
configure an optional default username and group name. These defaults are applied to all users that
match a service policy rule for Cloud Web Security.
Authentication Keys
Each ASA must use an authentication key that you obtain from Cloud Web Security. The authentication key
lets Cloud Web Security identify the company associated with web requests and ensures that the ASA is
associated with a valid customer.
You can use one of two types of authentication keys for your ASA: the company key or the group key.
• Company authentication key—You can use a company authentication key on multiple ASAs within
the same company. This key simply enables the Cloud Web Security service for your ASAs.
• Group authentication key—A Group authentication key is a special key unique to each ASA that
performs two functions:
◦Enables the Cloud Web Security service for one ASA.
◦Identifies all traffic from the ASA so you can create ScanCenter policy per ASA.
You generate these keys in ScanCenter (https://scancenter.scansafe.com/portal/admin/login.jsp). For more

information, see the Cloud Web Security documentation:
http://www.cisco.com/c/en/us/support/security/cloud-web-security/
products-installation-and-configuration-guides-list.html
ScanCenter Policy
In ScanCenter, traffic is matched against policy rules in order until a rule is matched. Cloud Web Security
then applies the configured action for the rule, allowing or blocking the traffic, or warning the user. With
warnings, the user has the option to continue on to the web site.
You configure the URL filtering policies in ScanCenter, not in the ASA.
126
However, part of the policy is to whom the policy applies. User traffic can match a policy rule in ScanCenter
based on group association: a directory group or a custom group. Group information is included in the requests
redirected from the ASA, so you need to understand what group information you might get from the ASA.
Directory Groups
Directory groups define the group to which traffic belongs. When using the identity firewall, the group, if
present, is included in the client’s HTTP request. If you do not use identity firewall, you can configure a default
group for traffic matching an ASA rule for Cloud Web Security inspection.
In ScanCenter, when you configure a directory group in a policy, you must enter the group name exactly.
• Identity firewall group names are sent in the following format.
domain-name\group-name
Note that on the ASA, the format is domain-name\\group-name. However, the ASA modifies the name
to use only one backslash (\) to conform to typical ScanCenter notation when including the group in the
redirected HTTP request.
• The default group name is sent in the following format:
[domain\]group-name
On the ASA, you need to configure the optional domain name to be followed by 2 backslashes (\\);
however, the ASA modifies the name to use only one backslash (\) to conform to typical ScanCenter
notation. For example, if you specify “Cisco\\Boulder1,” the ASA modifies the group name to be
“Cisco\Boulder1” with only one backslash (\) when sending the group name to Cloud Web Security.
Custom Groups
Custom groups are defined using one or more of the following criteria:
• ScanCenter Group authentication key—You can generate a Group authentication key for a custom group.
Then, if you identify this group key when you configure the ASA, all traffic from the ASA is tagged
with the Group key.
• Source IP address—You can identify source IP addresses in the custom group. Note that the ASA service
policy is based on source IP address, so you might want to configure any IP address-based policy on
the ASA instead.
• Username—You can identify usernames in the custom group.
◦Identity firewall usernames are sent in the following format:
domain-name\username
◦AAA usernames, when using RADIUS or TACACS+, are sent in the following format:
LOCAL\username
◦AAA usernames, when using LDAP, are sent in the following format:
domain-name\username
◦For the default username, it is sent in the following format:
[domain-name\]username
127
Licensing Requirements for Cisco Cloud Web Security
For example, if you configure the default username to be “Guest,” then the ASA sends “Guest.” If
you configure the default username to be “Cisco\Guest,” then the ASA sends “Cisco\Guest.”
How Groups and the Authentication Key Interoperate

Unless you need the per-ASA policy that a custom group plus group key provides, you will likely use a
company key. Note that not all custom groups are associated with a group key. You can use non-keyed custom
groups to identify IP addresses or usernames, and use them in your policy along with rules that use directory
groups.
Even if you do want per-ASA policy and are using a group key, you can also use the matching capability
provided by directory groups and non-keyed custom groups. In this case, you might want an ASA-based
policy, with some exceptions based on group membership, IP address, or username. For example, if you want
to exempt users in the America\Management group across all ASAs:
1 Add a directory group for America\Management.
2 Add an exempt rule for this group.
3 Add rules for each custom group plus group key after the exempt rule to apply policy per-ASA.
4 Traffic from users in America\Management will match the exempt rule, while all other traffic will match
the rule for the ASA from which it originated.
Many combinations of keys, groups, and policy rules are possible.
Failover from Primary to Backup Proxy Server

When you subscribe to the Cisco Cloud Web Security service, you are assigned a primary Cloud Web Security
proxy server and backup proxy server.
If any client is unable to reach the primary server, then the ASA starts polling the tower to determine availability.
(If there is no client activity, the ASA polls every 15 minutes.) If the proxy server is unavailable after a
configured number of retries (the default is 5; this setting is configurable), the server is declared unreachable,
and the backup proxy server becomes active.
After a failover to the backup server, the ASA continues to poll the primary server. If the primary server
becomes reachable, then the ASA returns to using the primary server.
You can also choose how the ASA handles web traffic when it cannot reach either the primary or backup
Cloud Web Security proxy server. It can block or allow all web traffic. By default, it blocks web traffic.
Licensing Requirements for Cisco Cloud Web Security

Model License Requirement
ASAv Standard or Premium License.
All other models Strong Encryption (3DES/AES) License to encrypt traffic between the ASA and the Cloud Web Security
server.
128
Guidelines for Cloud Web Security
On the Cloud Web Security side, you must purchase a Cisco Cloud Web Security license and identify the
number of users that the ASA handles. Then log into ScanCenter and generate your authentication keys.
Guidelines for Cloud Web Security

Context Mode Guidelines
Supported in single and multiple context modes.
In multiple context mode, the server configuration is allowed only in the system context, and the service policy
rule configuration is allowed only in the security contexts.
Each context can have its own authentication key, if desired.
Firewall Mode Guidelines

Supported in routed firewall mode only. Does not support transparent firewall mode.
IPv6 Guidelines
Does not support IPv6. Cloud Web Security currently supports only IPv4 addresses. If you use IPv6 internally,
use NAT 64 to translate IPv6 addresses to IPv4 for any IPv6 flows that need to be sent to Cloud Web Security.
• Cloud Web Security is not supported with ASA clustering.
• You cannot use Cloud Web Security on the same traffic you redirect to a module that can also perform
URL filtering, such as ASA CX and ASA FirePOWER. The traffic is sent to the modules only, not to
the Cloud Web Security servers.
• Clientless SSL VPN is not supported with Cloud Web Security; be sure to exempt any clientless SSL
VPN traffic from the ASA service policy for Cloud Web Security.
• When an interface to the Cloud Web Security proxy servers goes down, output from the show scansafe
server command shows both servers up for approximately 15-25 minutes. This condition may occur
because the polling mechanism is based on the active connection, and because that interface is down, it
shows zero connection, and it takes the longest poll time approach.
• Cloud Web Security inspection is compatible with HTTP inspection for the same traffic.
• Cloud Web Security is not supported with extended PAT or any application that can potentially use the
same source port and IP address for separate connections. For example, if two different connections
(targeted to separate servers) use extended PAT, the ASA might reuse the same source IP and source
port for both connection translations because they are differentiated by the separate destinations. When
the ASA redirects these connections to the Cloud Web Security server, it replaces the destination with
the Cloud Web Security server IP address and port (8080 by default). As a result, both connections now
appear to belong to the same flow (same source IP/port and destination IP/port), and return traffic cannot
be untranslated properly.
• The default inspection traffic class does not include the default ports for the Cloud Web Security inspection
(80 and 443).
129
Configure Cisco Cloud Web Security

Before you configure Cloud Web Security, obtain a license and the addresses of the proxy servers you will
use. Also, generate your authentication keys. Learn more about at Cloud Web Security http://www.cisco.com/
go/cloudwebsecurity.
Use the following process to configure the ASA to redirect web traffic to Cloud Web Security.
Before You Begin

If you want to send user identity information to Cloud Web Security, configure one of the following on the
ASA:
• Identity firewall (username and group).
• AAA rules (username only)—See the legacy feature guide.
If you want to use fully-qualified domain names (FQDN), such as www.example.com, you must configure
a DNS server for the ASA.
Procedure
Step 1 Configure Communications with the Cloud Web Security Proxy Server, on page 130.
Step 2 (Optional.) Identify Whitelisted Traffic, on page 131.
Step 3 Configure a Service Policy to Send Traffic to Cloud Web Security, on page 133.
Step 4 (Optional.) Configure the User Identity Monitor, on page 138
Step 5 Configure the Cloud Web Security Policy, on page 139.
Configure Communications with the Cloud Web Security Proxy Server

You must identify the Cloud Web Security proxy servers so that user web requests can be redirected properly.
In multiple context mode, you must configure the proxy servers in the system context, then enable Cloud Web
Security per context. Thus, you can use the service in some contexts but not in others.
Before You Begin

• You must configure a DNS server for the ASA to use fully-qualified domain names for the proxy servers.
• (Multiple context mode.) You must configure a route pointing to the Cloud Web Security proxy servers
in both the system context and the specific contexts. This ensures that the Cloud Web Security proxy
servers do not become unreachable in the Active/Active failover scenario.
Procedure
Step 1 Choose Configuration > Device Management > Cloud Web Security. In multiple context mode, do this
in the system context.
130
Step 2 Identify the primary and backup servers by IP address or fully-qualified domain name.
When you subscribe to the Cisco Cloud Web Security service, you are assigned primary and backup Cloud
Web Security proxy servers.
By default, the Cloud Web Security proxy server uses port 8080 for both HTTP and HTTPS traffic; do not
change this value unless directed to do so.
Step 3 In the Other area, enter the following:

• Retry Counter—The number of consecutive polling failures to the Cloud Web Security proxy server
before determining the server is unreachable. Polls are performed every 30 seconds. Valid values are
from 2 to 100, and the default is 5.
• License Key, Confirm License Key—The authentication key that the ASA sends to the Cloud Web
Security proxy servers to indicate from which organization the request comes. The authentication key
is a 16-byte hexidecimal number. It can be a company or group key.
Step 4 Click Apply.

Step 5 (Multiple context mode only.) Switch to each context where you want to use the service and enable it.
You can optionally enter a separate authentication key for each context. If you do not include an authentication
key, the one configured for the system context is used.
Identify Whitelisted Traffic

If you use identity firewall or AAA rules, you can configure the ASA so that web traffic from specific users
or groups that otherwise match the service policy rule is not redirected to the Cloud Web Security proxy server
for scanning. This process is called “whitelisting” traffic.
You configure the whitelist in a ScanSafe inspection class map. You can use usernames and group names
derived from both identity firewall and AAA rules. You cannot whitelist based on IP address or on destination
URL.
131
When you configure your Cloud Web Security service policy rule, you refer to the class map in your policy.
Although you can achieve the same results of exempting traffic based on user or group when you configure
the traffic matching criteria (with ACLs) in the service policy rule, you might find it more straightforward to
use a whitelist instead.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Class Maps > Cloud Web Security.
• Click Add to add a new class map. Enter a map name, 40 characters or less, and optionally, a description.
• Select a map and click Edit.
Step 3 Choose a match option: Match All or Match Any.

Match All is the default, and specifies that traffic must match all criteria to match the class map. Match Any
means that traffic matches the class map if it matches at least one criterion.
Step 4 Configure the match criteria by adding or editing entries in the match table. Add as many as required to define
the targeted traffic.
a) Choose the match type for the criteria: Match or No Match.
• Match—Specifies the user or group that you want to whitelist.
• No Match—Specifies the user or group that you do not want to whitelist; for example, if you whitelist
the group “cisco,” but you want to scan traffic from users “johncrichton” and “aerynsun,” you can
specify No Match for those users.
b) Choose whether you are defining a User, Group, or both, and enter the name of the user or group.
c) Click OK. Repeat the process until you add all your whitelist criteria.
132
Step 5 Click OK to add the class map.

Step 6 Click Apply.
You can now use the whitelist in the Cloud Web Security service policy.
Configure a Service Policy to Send Traffic to Cloud Web Security

Your service policy consists of multiple service policy rules, applied globally, or applied to each interface.
Each service policy rule can either send traffic to Cloud Web Security (Match) or exempt traffic from Cloud
Web Security (Do Not Match).
Create rules for traffic destined for the Internet. The order of these rules is important. When the ASA decides
whether to forward or exempt a packet, the ASA tests the packet with each rule in the order in which the rules
are listed. After a match is found, no more rules are checked. For example, if you create a rule at the beginning
of a policy that explicitly Matches all traffic, no further statements are ever checked.
Before You Begin

If you need to use a whitelist to exempt some traffic from being sent to Cloud Web Security, first create the
whitelist so you can refer to it in your service policy rule.
Procedure
Step 1 Choose Configuration > Firewall > Service Policy, and open a rule.
• To create a new rule, click Add > Add Service Policy Rule. When adding a policy, you can apply it to
a specific interface or globally to all interfaces. If there is already a global policy, or a policy for the
interface, you are adding a rule to the existing policy. You can name new rules. Click Next to proceed.
133
• If you have a ScanSafe inspection rule, or a rule to which you are adding ScanSafe inspection, select it
and click Edit. Note that the “inspection_default” rule in the Global folder does not include the HTTP
and HTTPS ports, so you cannot add ScanSafe inspection to that rule.
Step 2 On the Traffic Classification Criteria page, choose one of the following options to specify the traffic to which
to apply the policy actions and click Next. When creating a new class, give the class a meaningful name. Also
note that you must create separate classes for HTTP and HTTPS traffic.
• Create a new traffic class > Source and Destination IP Address (uses ACL)—If you do not already
have a traffic class for Cloud Web Security, we recommend this option because ACL matching is the
most flexible way to define the class.
When you create a new traffic class of this type, you can only specify one access control entry (ACE)
initially. After you finish adding the rule, you can add additional ACEs by adding a new rule to the same
interface or global policy, and then specifying Add rule to existing traffic class.
• Create a new traffic class > TCP or UDP Port—Use this option if you do not want to differentiate
among web traffic. When you click Next, specify one port, either TCP http or TCP https.
• Add rule to existing traffic class—If you have already started an ACL for Cisco Cloud Web Security
inspection, and you are adding rules to the existing policy, select this option and select the traffic class.
Step 3 (ACL matching.) When defining the traffic class based on source and destination criteria, fill in the ACL
attributes for this rule.
a) Click Match or Do Not Match.
Match specifies that traffic matching the source and destination is sent to Cloud Web Security. Do Not
Match exempts matching traffic from Cloud Web Security. You can later add additional rules to match
or not match other traffic.
When creating your rules, consider how you can match appropriate traffic that is destined for the Internet,
but not match traffic that is destined for other internal networks. For example, to prevent inside traffic
from being sent to Cloud Web Security when the destination is an internal server on the DMZ, be sure to
add a deny ACE to the ACL that exempts traffic to the DMZ.
b) In the Source Criteria area, enter or browse for a Source IP address or network object. You can also use
identity firewall user arguments and Cisco Trustsec security groups to help identify traffic. Note that
Trustsec security group information is not sent to Cloud Web Security; you cannot define policy based
on security group.
c) In the Destination Criteria area, enter or browse for a Destination IP address or network object, and an
optional TrustSec Security Group.
134
FQDN network objects might be useful in matching or exempting traffic to specific servers.
d) In the Service field, enter http or https, and click Next.
Note Cloud Web Security only operates on HTTP and HTTPS traffic. Each type of traffic is treated
separately by the ASA. Therefore, you need to create HTTP-only rules and HTTPS-only rules.
Step 4 On the Rule Actions page, Protocol Inspection tab, check the Cloud Web Security check box.
Step 5 Click Configure to set the traffic action and add the inspection policy map.
The inspection policy map configures essential parameters for the rule and also optionally identifies the
whitelist. An inspection policy map is required for each class of traffic that you want to send to Cloud Web
Security. You can also pre-configure inspection policy maps by choosing Configuration > Firewall > Objects
> Inspect Maps > Cloud Web Security.
a) For the Cloud Web Security Traffic Action, choose one:
• Fail Close—Drops all traffic if the Cloud Web Security servers are unavailable.
• Fail Open—Allows traffic to pass through the ASA if the Cloud Web Security servers are unavailable.
135
b) Choose an existing inspection policy map, or click Add to add a new map.
c) (New maps only.) In the Cloud Web Security Inspection Map dialog box, enter a name for the map and
configure the following attributes. Click OK when finished.
• Default User and Group—(Optional.) The default user or group name, or both. If the ASA cannot
determine the identity of the user coming into the ASA, then the default user and group is included
in the HTTP request sent to Cloud Web Security. You can define policies in ScanCenter for this user
or group name.
• Protocol—Select HTTP or HTTPS based on the service you selected in the traffic class. These
selections must match. Cloud Web Security treats each type of traffic separately.
136
• Inspections tab—(Optional) To identify a whitelist, click the Add on the Inspections tab and select
the class map for the whitelist. You can also add a whitelist at this time by clicking Manage. Ensure
that Whitelist is selected as the action and click OK. You can add additional whitelists.
d) Click OK in the Select Cloud Web Security Inspect Map dialog box.
Step 6 Click Finish. The rule is added to the Service Policy Rules table.
Step 7 To add additional sub-rules (ACEs) for this traffic class, to match or exempt additional traffic, repeat the
process, selecting the same interface or global policy. When you configure the traffic class, select the option
to Add rule to existing traffic class, and select the Cloud Web Security class.
When you configure the new ACE, ensure that you specify the same service used by the other rules in the
class, either HTTP or HTTPS.
Do not make changes to the Rule Actions page. Click Finish when the rule is complete.
137
Step 8 Repeat this entire procedure to create traffic class for the other protocol, for example for HTTPS traffic
(assuming you started with an HTTP traffic class). You can create as many rules and sub-rules as needed.
Step 9 Arrange the order of Cloud Web Security rules and sub-rules on the Service Policy Rules pane. Select the
rule you want to move and click the up or down buttons. Ensure that specific rules come before more general
rules.
Step 10 Click Apply.
Configure the User Identity Monitor

When you use identity firewall, the ASA only downloads user identity information from the AD server for
users and groups included in active ACLs. The ACL must be used in a feature such as an access rule, AAA
rule, service policy rule, or other feature to be considered active.
For example, although you can configure your Cloud Web Security service policy rule to use an ACL with
users and groups, thus activating any relevant groups, it is not required. You could use an ACL based entirely
on IP addresses.
138
Monitoring Cloud Web Security
Because Cloud Web Security can base its ScanCenter policy on user identity, you might need to download
groups that are not part of an active ACL to get full identity firewall coverage for all your users. The user
identity monitor lets you download group information directly from the AD agent.
Note The ASA can only monitor a maximum of 512 groups, including those configured for the user identity
monitor and those monitored through active ACLs.
Procedure
Step 1 Choose Configuration > Firewall > Identity Options, and scroll to the Cloud Web Security Configuration
section.
Step 2 Click Add.
Step 3 Select the domain that includes the group, then double-click the group in the user groups list and click OK
to add it. Repeat the process to add more groups.
• If there are a large number of groups, use the Find box to filter the list. The ASA downloads names
from AD for the specified domain.
• You can also type in a group name directly in the format domain_name\\group_name.
• If necessary, you can add new domains by clicking the Manage button.
Step 4 After you add the all the groups you want to monitor, click Apply.
Configure the Cloud Web Security Policy

After you configure the ASA service policy rules, launch the ScanCenter Portal to configure Web content
scanning, filtering, malware protection services, and reports.
Go to: https://scancenter.scansafe.com/portal/admin/login.jsp.
For more information, see the Cisco ScanSafe Cloud Web Security Configuration Guides:
http://www.cisco.com/en/US/products/ps11720/products_installation_and_configuration_guides_list.html
Monitoring Cloud Web Security

To monitor Cloud Web Security, select Monitoring > Properties > Cloud Web Security. This page shows
the proxy server status and statistics for redirected HTTP/HTTPS connections. In multiple context mode,
statistics are only shown within a context.
You can determine if a user’s traffic is being redirected to the proxy servers by accessing the following URL
from the client machine. The page will show a message indicating whether the user is currently using the
service.
http://Whoami.scansafe.net
139
Examples for Cisco Cloud Web Security

Following are some examples for configuring Cloud Web Security.
Example Service Policy for Cloud Web Security

The following example exempts all IPv4 HTTP and HTTPS traffic going to the 10.6.6.0/24 network, sends
all other HTTPS and HTTPS traffic to Cloud Web Security, and applies this service policy rule to all interfaces
as part of the existing global policy. If the Cloud Web Security server is unreachable, the ASA drops all
matching traffic (fail close). If a user does not have user identity information, the default user Boulder and
group Cisco is used.
Procedure
Step 1 Choose Configuration > Firewall > Service Policy Rules, and click Add > Service Policy Rule. Add
this rule to the default global_policy. Click Next.
Step 2 Add a new traffic class called “scansafe-http,” and specify an ACL for traffic matching. Click Next.
140
Step 3 Choose Match, and specify any4 for the Source and Destination. Specify tcp/http for the Service. Click
Next.
Step 4 Check Cloud Web Security on the Protocol Inspection tab and click Configure.
Step 5 Accept the default Fail Close action, and click Add.
141
Step 6 Name the inspection policy map “http-map,” set the Default User to Boulder and the default group to Cisco.
Choose HTTP.
Step 7 Click OK, OK, and then Finish. The rule is added to the Service Policy Rules table.
142
Step 8 Choose Configuration > Firewall > Service Policy Rules, and click Add > Service Policy Rule. Add
the new rule to the default global_policy and click Next.
Step 9 Click Add rule to existing traffic class, and choose scansafe-http.
143
Step 10 Choose Do not match, set any4 as the Source, and 10.6.6.0/24 as the Destination. Set the Service to tcp/http.
Click Next.
Step 11 Click Finish.

Step 12 Reorder the rules so the Do not match rule is above the Match rule.
User traffic is compared to these rules in order; if this Match rule is first in the list, then all traffic, including
traffic to the test network, will match only that rule and the Do not match rule will never be hit. If you move
the Do not match rule above the Match rule, then traffic to the test network will match the Do not match rule,
and all other traffic will match the Match rule.
Step 13 Repeat the above steps with the following changes: add a new traffic class called “scansafe-https,” and choose
HTTPS for the inspection policy map.
144
History for Cisco Cloud Web Security

Feature Name Platform Feature Information
Releases
Cloud Web Security 9.0(1) This feature was introduced.
Cisco Cloud Web Security provides content scanning and other
malware protection service for web traffic. It can also redirect
and report about web traffic based on user identity.
Configuration > Device Management > Cloud Web Security
Configuration > Firewall > Objects > Class Maps > Cloud Web
Security Configuration > Firewall > Objects > Inspect Maps >
Cloud Web Security Configuration > Firewall > Identity
Options Configuration > Firewall > Service Policy Rules
Monitoring > Properties > Cloud Web Security
145
146
PART II
• Network Address Translation (NAT), page 149
• NAT Examples and Reference, page 211
CHAPTER 9
Network Address Translation (NAT)
The following topics explain Network Address Translation (NAT) and how to configure it.
• Why Use NAT?, page 149

• NAT Basics, page 150
• Guidelines for NAT, page 154
• Dynamic NAT, page 160
• Dynamic PAT, page 168
• Static NAT, page 187
• Identity NAT, page 199
• Monitoring NAT, page 206
• History for NAT, page 206
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:
149
NAT Basics
• Security—Keeping internal IP addresses hidden discourages direct attacks.

• IP routing solutions—Overlapping IP addresses are not a problem when you use NAT.
• Flexibility—You can change internal IP addressing schemes without affecting the public addresses
available externally; for example, for a server accessible to the Internet, you can maintain a fixed IP
address for Internet use, but internally, you can change the server address.
• Translating between IPv4 and IPv6 (Routed mode only) (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:
150
NAT Basics
• 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 160.
• 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 168.
• Static NAT—A consistent mapping between a real and mapped IP address. Allows bidirectional traffic
initiation. See Static NAT, on page 187.
• 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 199.
Network Object NAT and Twice NAT

You can implement address translation in two ways: network object NAT and twice NAT.
We recommend using network object NAT unless you need the extra features that twice NAT provides. It is
easier to configure network object 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.)
Network Object NAT

All NAT rules that are configured as a parameter of a network object are considered to be network object 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.
After you configure the network object, you can then identify the mapped address for that object, either as an
inline address or as another network object or network object group.
When a packet enters an interface, both the source and destination IP addresses are checked against the network
object 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 twice NAT for that kind of functionality, where you can identify
the source and destination address in a single rule.
Twice NAT
Twice 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.
151
NAT Basics
Note For static NAT, the rule is bidirectional, so be aware that “source” and “destination” are used in commands
and descriptions throughout this guide even though a given connection might originate at the “destination”
address. For example, if you configure static NAT with port address translation, and specify the source
address as a Telnet server, and you want all traffic going to that Telnet server to have the port translated
from 2323 to 23, then you must specify the source ports to be translated (real: 23, mapped: 2323). You
specify the source ports because you specified the Telnet server address as the source address.
The destination address is optional. If you specify the destination address, you can either map it to itself
(identity NAT), or you can map it to a different address. The destination mapping is always a static mapping.
Comparing Network Object NAT and Twice NAT

The main differences between these two NAT types are:
• How you define the real address.
◦Network object NAT—You define NAT as a parameter for a network object. A network object
names an IP host, range, or subnet so you can then use the object in the NAT configuration instead
of the actual IP addresses. The network object IP address serves as the real address. This method
lets you easily add NAT to network objects that might already be used in other parts of your
configuration.
◦Twice 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 twice NAT is more scalable.
• How source and destination NAT is implemented.

◦Network Object 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.
◦Twice 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 twice 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.

◦Network Object NAT—Automatically ordered in the NAT table.
◦Twice NAT—Manually ordered in the NAT table (before or after network object NAT rules).
152
NAT Basics
NAT Rule Order

Network Object NAT and twice 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 9: NAT Rule Table
Table Section Rule Type Order of Rules within the Section

Section 1 Twice 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, twice NAT rules
are added to section 1.
Section 2 Network Object 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 Twice 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)
153
Guidelines for NAT
• 192.168.1.1/32 (static)
• 172.16.1.0/24 (dynamic) (object def)
• 172.16.1.0/24 (dynamic) (object abc)
The resultant ordering would be:

• 192.168.1.1/32 (static)
• 10.1.1.0/24 (static)
• 192.168.1.0/24 (static)
• 172.16.1.0/24 (dynamic) (object abc)
• 172.16.1.0/24 (dynamic) (object def)
• 192.168.1.0/24 (dynamic)
NAT Interfaces
In routed mode, 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 16: Specifying Any Interface
In transparent mode, you must choose specific source and destination interfaces.
Guidelines for NAT

The following topics provide detailed guidelines for implementing NAT.
154
Guidelines for NAT
Firewall Mode Guidelines for NAT

NAT is supported in routed and transparent firewall mode. However, transparent mode has the following
restrictions:
• In transparent mode, you must specify the real and mapped interfaces; you cannot specify “any” as the
interface. The interfaces must be part of a bridge group (BVI) interface.
• In transparent mode, you cannot configure interface PAT, because the transparent mode interfaces do
not have IP addresses. You also cannot use the management IP address as a mapped address.
• In transparent mode, translating between IPv4 and IPv6 networks is not supported. Translating between
two IPv6 networks, or between two IPv4 networks is supported.
IPv6 NAT Guidelines

NAT supports IPv6 with the following guidelines and restrictions.
• For routed mode, you can also translate between IPv4 and IPv6.
• For transparent mode, translating between IPv4 and IPv6 networks is not supported. Translating between
two IPv6 networks, or between two IPv4 networks is supported.
• For transparent mode, a PAT pool is not supported for IPv6.
• 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:
• 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 (twice 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 (twice 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.
155
Guidelines for NAT
• 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.
Additional Guidelines for NAT

• (Network Object 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.
• (Twice NAT only.) You cannot configure destination port translation for FTP, or for any other application
that uses a secondary connection, when the source IP address is a subnet; the FTP data channel
establishment does not succeed.
• 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.
• When translating SCTP traffic, use static network object NAT only. Dynamic NAT/PAT is not allowed.
Although you can configure static twice NAT, this is not recommended because the topology of the
destination part of the SCTP association is unknown.
• Objects and object groups used in NAT cannot be undefined; they must include IP addresses.
• You cannot use an object group with both IPv4 and IPv6 addresses; the object group must include only
one type of address.
• (Twice 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 ASA performs NAT on a packet, the packet must be
IPv6-to-IPv6 or IPv4-to-IPv4; with this prerequisite, the ASA 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.
◦(Transparent mode.) The management IP address.
◦Existing VPN pool addresses.
156
Guidelines for NAT
• 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.
• For application inspection limitations with NAT or PAT, see Default Inspections and NAT Limitations,
on page 284.
• (8.3(1), 8.3(2), and 8.4(1)) The default behavior for identity NAT has proxy ARP disabled. You cannot
configure this setting. (8.4(2) and later) The default behavior for identity NAT has proxy ARP enabled,
matching other static NAT rules. You can disable proxy ARP if desired. See Routing NAT Packets, on
page 241 for more information.
• 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. In 8.3(1) through 8.4(1), identity NAT always uses the routing table.
• You can improve system performance and reliability by using the transactional commit model for NAT.
See the basic settings chapter in the general operations configuration guide for more information. The
option is under Configurations > Device Management > Advanced > Rule Engine.
Network Object NAT Guidelines for Mapped Address Objects

For dynamic NAT, you must use an object or group for the mapped addresses. For the other NAT types, you
can use an object or group, or you have the option of using inline addresses. Network object groups are
particularly useful for creating a mapped address pool with discontinuous IP address ranges or multiple hosts
or subnets.
Consider the following guidelines when creating objects for mapped addresses.
• A network object group can contain objects or inline addresses of either IPv4 or IPv6 addresses. The
group cannot contain both IPv4 and IPv6 addresses; it must contain one type only.
• See Additional Guidelines for NAT, on page 156 for information about disallowed mapped IP addresses.
• Dynamic NAT:
◦You cannot use an inline address; you must configure a network object or group.
◦The object or group cannot contain a subnet; the object must define a range; the group can include
hosts and ranges.
◦If a mapped network object 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 (Hide):

◦Instead of using an object, you can optionally configure an inline host address or specify the
interface address.
◦If you use an object, the object or group cannot contain a subnet. The object must define a host,
or for a PAT pool, a range. The group (for a PAT pool) can include hosts and ranges.
• Static NAT or Static NAT with port translation:

◦Instead of using an object, you can configure an inline address or specify the interface address (for
static NAT-with-port-translation).
157
Guidelines for NAT
◦If you use an object, the object or group can contain a host, range, or subnet.
• Identity NAT
◦Instead of using an object, you can configure an inline address.
◦If you use an object, the object must match the real addresses you want to translate.
Twice NAT Guidelines for Real and Mapped Address Objects

For each NAT rule, configure up to four network objects or groups for:
• Source real address
• Source mapped address
• Destination real address
• Destination mapped address
Objects are required unless you specify the any keyword inline to represent all traffic, or for some types of
NAT, the interface keyword to represent the interface address. Network object groups are particularly useful
for creating a mapped address pool with discontinuous IP address ranges or multiple hosts or subnets.
Consider the following guidelines when creating objects for twice NAT.
• A network object group can contain objects or inline addresses of either IPv4 or IPv6 addresses. The
group cannot contain both IPv4 and IPv6 addresses; it must contain one type only.
• See Additional Guidelines for NAT, on page 156 for information about disallowed mapped IP addresses.
• Source Dynamic NAT:
◦You typically configure a larger group of real addresses to be mapped to a smaller group.
◦The mapped object or group cannot contain a subnet; the object must define a range; the group
can include hosts and ranges.
◦If a mapped network object contains both ranges and host IP addresses, then the ranges are used
for dynamic NAT, and the host IP addresses are used as a PAT fallback.
• Source Dynamic PAT (Hide):

◦If you use an object, the object or group cannot contain a subnet. The object must define a host,
or for a PAT pool, a range. The group (for a PAT pool) can include hosts and ranges.
• Source Static NAT or Static NAT with port translation:

◦The mapped object or group can contain a host, range, or subnet.
◦The static mapping is typically one-to-one, so the real addresses have the same quantity as the
mapped addresses. You can, however, have different quantities if desired.
• Source Identity NAT

◦The real and mapped objects must match. You can use the same object for both, or you can create
separate objects that contain the same IP addresses.
158
Guidelines for NAT
• Destination Static NAT or Static NAT with port translation (the destination translation is always static):
◦Although the main feature of twice NAT is the inclusion of the destination IP address, the destination
address is optional. If you do specify the destination address, you can configure static translation
for that address or just use identity NAT for it. You might want to configure twice NAT without
a destination address to take advantage of some of the other qualities of twice NAT, including the
use of network object groups for real addresses, or manually ordering of rules. For more information,
see Comparing Network Object NAT and Twice NAT, on page 152.
◦For identity NAT, the real and mapped objects must match. You can use the same object for both,
or you can create separate objects that contain the same IP addresses.
◦The static mapping is typically one-to-one, so the real addresses have the same quantity as the
◦For static interface NAT with port translation (routed mode only), you can specify the interface
keyword instead of a network object/group for the mapped address.
Twice NAT Guidelines for Service Objects for Real and Mapped Ports
You can optionally configure service objects for:
• Source real port (Static only) or Destination real port
• Source mapped port (Static only) or Destination mapped port
Consider the following guidelines when creating objects for twice NAT.
• NAT supports TCP, UDP, and SCTP only. When translating a port, be sure the protocols in the real and
mapped service objects are identical (for example, both TCP). Although you can configure static twice
NAT rules with SCTP port specifications, this is not recommended, because the topology of the destination
part of the SCTP association is unknown. Use static object NAT instead for SCTP.
• The “not equal” (neq) operator is not supported.
• For identity port translation, you can use the same service object for both the real and mapped ports.
• Source Dynamic NAT—Source Dynamic NAT does not support port translation.
• Source Dynamic PAT (Hide)—Source Dynamic PAT does not support port translation.
• Source Static NAT, Static NAT with port translation, or Identity NAT—A service object can contain
both a source and destination port; however, you should specify either the source or the destination port
for both service objects. You should only specify both the source and destination ports if your application
uses a fixed source port (such as some DNS servers); but fixed source ports are rare. For example, if
you want to translate the port for the source host, then configure the source service.
• Destination Static NAT or Static NAT with port translation (the destination translation is always
static)—For non-static source NAT, you can only perform port translation on the destination. A service
object can contain both a source and destination port, but only the destination port is used in this case.
If you specify the source port, it will be ignored.
159
Dynamic NAT
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 17: Dynamic NAT
160
Dynamic NAT
The following figure shows a remote host attempting to initiate a connection to a mapped address. This address
is not currently in the translation table; therefore, the packet is dropped.
Figure 18: 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.
See Default Inspections and NAT Limitations, on page 284 for more information about NAT and PAT support.
Configure Dynamic Network Object NAT

This section describes how to configure network object NAT for dynamic NAT.
161
Dynamic NAT
Procedure
Step 1 Add NAT to a new or existing network object:

• To add a new network object, choose Configuration > Firewall > NAT Rules, then click Add > Add
Network Object NAT Rule.
• To add NAT to an existing network object, choose Configuration > Firewall > Objects > Network
Objects/Groups, and then edit a network object.
Step 2 For a new object, enter values for the following fields:
a) Name—The object name. Use characters a to z, A to Z, 0 to 9, a period, a dash, a comma, or an underscore.
The name must be 64 characters or less.
b) Type—Host, Network, or Range.
c) IP Addresses—IPv4 or IPv6 addresses, a single address for a host, a starting and ending address for a
range, and for subnet, either an IPv4 network address and mask (for example, 10.100.10.0 255.255.255.0)
or IPv6 address and prefix length (for example, 2001:DB8:0:CD30::/60).
Step 3 If the NAT section is hidden, click NAT to expand the section.
162
Dynamic NAT
Step 4 Check the Add Automatic Translation Rules check box.

Step 5 From the Type drop-down list, choose Dynamic.
Step 6 To the right of the Translated Addr field, click the browse button and choose the network object or network
object group that contains the mapped addresses.
You can create a new object if necessary.
The object or group cannot contain a subnet. The group cannot contain both IPv4 and IPv6 addresses; it must
contain one type only.
Step 7 (Optional, Routed Mode Only) To use the interface IP address as a backup method when the other mapped
addresses are already allocated, check the Fall through to interface PAT (dest intf) check box, and choose
the interface from the drop-down list. To use the IPv6 address of the interface, also check the Use IPv6 for
interface PAT check box.
Step 8 (Optional) Click Advanced, configure the following options in the Advanced NAT Settings dialog box, and
click OK.
• Translate DNS replies for rule—Translates the IP address in DNS replies. Be sure DNS inspection is
enabled (it is enabled by default). See DNS and NAT, on page 250 for more information.
• (Required for Transparent Firewall Mode.) Interface—Specifies the real interface (Source) and the
mapped interface (Destination) where this NAT rule applies. By default, the rule applies to all interfaces.
Configure Dynamic Twice NAT

This section describes how to configure twice NAT for dynamic NAT.
Procedure
Step 1 Choose Configuration > Firewall > NAT Rules, and then do one of the following:
• Click Add, or Add > Add NAT Rule Before Network Object NAT Rules.
• Click Add > Add NAT Rule After Network Object NAT Rules.
• Select a twice NAT rule and click Edit.
The Add NAT Rule dialog box appears.
163
Dynamic NAT
Step 2 Set the source and destination interfaces.

By default in routed mode, both interfaces are set to --Any--. In transparent firewall mode, you must set
specific interfaces.
a) From the Match Criteria: Original Packet > Source Interface drop-down list, choose the source interface.
b) From the Match Criteria: Original Packet > Destination Interface drop-down list, choose the destination
interface.
Step 3 Choose Dynamic from the Action: Translated Packet > Source NAT Type drop-down list.
This setting only applies to the source address; the destination translation is always static.
164
Dynamic NAT
Step 4 Identify the original packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on
the source interface network (the real source address and the mapped destination address). See the following
figure for an example of the original packet vs. the translated packet.
a) For the Match Criteria: Original Packet > Source Address, click the browse button and choose an
existing network object or group or create a new object or group from the Browse Original Source Address
dialog box. The group cannot contain both IPv4 and IPv6 addresses; it must contain one type only. The
default is any.
b) (Optional.) For the Match Criteria: Original Packet > Destination Address, click the browse button
and choose an existing network object, group, or interface, or create a new object or group from the Browse
Original Destination Address dialog box. A group cannot contain both IPv4 and IPv6 addresses; it must
Although the main feature of twice NAT is the inclusion of the destination IP address, the destination
address is optional. If you do specify the destination address, you can configure static translation for that
address or just use identity NAT for it. You might want to configure twice NAT without a destination
address to take advantage of some of the other qualities of twice NAT, including the use of network object
groups for real addresses, or manually ordering of rules. For more information, see Comparing Network
Object NAT and Twice NAT, on page 152.
For static interface NAT with port translation only, choose an interface from the Browse dialog box. Be
sure to also configure a service translation. For this option, you must configure a specific interface for the
Source Interface. See Static Interface NAT with Port Translation for more information.
Step 5 Identify the translated packet addresses, either IPv4 or IPv6; namely, the packet addresses as they appear on
the destination interface network (the mapped source address and the real destination address). You can
translate between IPv4 and IPv6 if desired.
a) For Action: Translated Packet > Source Address, click the browse button and choose an existing network
object or group or create a new object or group from the Browse Translated Source Address dialog box.
For dynamic NAT, you typically configure a larger group of source addresses to be mapped to a smaller
group.
Note The object or group cannot contain a
subnet.
b) For Action: Translated Packet > Destination Address, click the browse button and choose an existing
network object or group, or create a new object or group from the Browse Translated Destination Address
dialog box.
For identity NAT for the destination address, simply use the same object or group for both the real and
mapped addresses.
If you want to translate the destination address, then the static mapping is typically one-to-one, so the real
addresses have the same quantity as the mapped addresses. You can, however, have different quantities
165
Dynamic NAT
if desired. For more information, see Static NAT, on page 187. See Additional Guidelines for NAT, on
page 156 for information about disallowed mapped IP addresses.
Step 6 (Optional.) Identify the destination service ports for service translation.
• Identify the original packet port (the mapped destination port). For Match Criteria: Original Packet
> Service, click the browse button and choose an existing service object that specifies TCP or UDP
ports, or create a new object from the Browse Original Service dialog box.
• Identify the translated packet port (the real destination port). For Action: Translated Packet > Service,
click the browse button and choose an existing service object that specifies TCP or UDP ports, or create
a new object from the Browse Translated Service dialog box.
Dynamic NAT does not support port translation. However, because the destination translation is always static,
you can perform port translation for the destination port. A service object can contain both a source and
destination port, but only the destination port is used in this case. If you specify the source port, it will be
ignored. 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. The “not equal” (!=) operator is not supported.
For example:
166
Dynamic NAT
Step 7 (Optional, Routed Mode Only.) To use the interface IP address as a backup method if the other mapped source
addresses are already allocated, check the Fall through to interface PAT check box. To use the IPv6 interface
address, also check the Use IPv6 for interface PAT check box.
The destination interface IP address is used. This option is only available if you configure a specific Destination
Interface.
Step 8 (Optional.) Configure NAT options in the Options area.
167
Dynamic PAT
• Enable rule —Enables this NAT rule. The rule is enabled by default.
• (For a source-only rule) Translate DNS replies that match this rule—Rewrites the DNS A record in
DNS replies. Be sure DNS inspection is enabled (it is enabled by default). You cannot configure DNS
modification if you configure a destination address. See DNS and NAT, on page 250 for more information.
• Description—Adds a description about the rule up to 200 characters in length.
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.
168
Dynamic PAT
The following figure shows a typical dynamic PAT scenario. Only real hosts can create a NAT session, and
responding traffic is allowed back. The mapped address is the same for each translation, but the port is
dynamically assigned.
Figure 19: 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. For multi-session PAT, the PAT timeout is
used, 30 seconds by default. For per-session PAT (9.0(1) and later), the xlate is immediately removed.
Dynamic PAT Disadvantages and Advantages

Dynamic PAT lets you use a single mapped address, thus conserving routable addresses. You can even use
the ASA interface IP address as the PAT address.
Dynamic PAT does not work with some multimedia applications that have a data stream that is different from
the control path. See Default Inspections and NAT Limitations, on page 284 for more information about NAT
and PAT support.
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 enable block allocation for a PAT pool, port blocks are allocated in the 1024-65535 range only.
Thus, if an application requires a low port number (1-1023), it might not work. For example, an application
requesting port 22 (SSH) will get a mapped port within the range of 1024-65535 and within the block
allocated to the host.
169
Dynamic PAT
• 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.
For extended PAT for a PAT pool

• Many application inspections do not support extended PAT. See Default Inspections and NAT
Limitations, on page 284 for a complete list of unsupported inspections.
• 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.
• 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 Network Object PAT (Hide)

This section describes how to configure network object NAT for dynamic PAT (hide), which uses a single
address for translation instead of a PAT pool.
Procedure

170
Dynamic PAT
Step 5 From the Type drop-down list, choose Dynamic PAT (Hide).
Step 6 Specify a single mapped address. In the Translated Addr. field, specify the mapped IP address by doing one
of the following:
• Type a host IP address.
• Click the browse button and select a host network object (or create a new one).
• (Routed mode only.) Type an interface name or click the browse button, and choose an interface from
the Browse Translated Addr dialog box.
If you specify an interface name, then you enable interface PAT, where the specified interface IP address
is used as the mapped address. To use the IPv6 interface address, you must also check the Use IPv6 for
171
Dynamic PAT
interface PAT check box. With interface PAT, the NAT rule only applies to the specified mapped
interface. (If you do not use interface PAT, then the rule applies to all interfaces by default.) You cannot
specify an interface in transparent mode.
Step 7 (Optional.) Click Advanced, configure the following options in the Advanced NAT Settings dialog box, and
click OK.
Configure Dynamic Network Object PAT Using a PAT Pool

This section describes how to configure network object NAT for dynamic PAT using a PAT pool.
Procedure

• To add a new network object NAT rule, choose Configuration > Firewall > NAT Rules, then click
Add > Add Network Object NAT Rule.
172
Dynamic PAT

Step 5 From the Type drop-down list, choose Dynamic even though you are configuring dynamic PAT with a PAT
pool.
Step 6 To configure the PAT pool:
a) Do not enter a value for the Translated Addr. field; leave it blank.
b) Check the PAT Pool Translated Address check box, then click the browse button and choose the network
object or group that contains the PAT pool addresses. or create a new object from the Browse Translated
PAT Pool Address dialog box.
Note The PAT pool object or group cannot contain a subnet. The group cannot contain both IPv4 and
IPv6 addresses; it must contain one type only.
c) (Optional) Select the following options as needed:
173
Dynamic 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.
• Extend PAT uniqueness to per destination instead of per interface (8.4(3) and later, not including
8.5(1) or 8.6(1).)—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.
• Translate TCP or UDP ports into flat range (1024-65535) (8.4(3) and later, not including 8.5(1)
or 8.6(1).)—To use the 1024 to 65535 port range as a single flat range when allocating ports. When
choosing the mapped port number for a translation, the ASA 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 range 1 to 1023 check box.
• Enable Block Allocation (9.5.1 and later.)—Enables port block allocation. For carrier-grade or
large-scale PAT, you can allocate a block of ports for each host, rather than have NAT allocate one
port translation at a time. If you allocate a block of ports, subsequent connections from the host use
new randomly-selected ports within the block. If necessary, additional blocks are allocated if the
host has active connections for all ports in the original block. Port blocks are allocated in the
1024-65535 range only. Port block allocation is compatible with round robin, but you cannot use it
with the extended PAT or flat port range options. You also cannot use interface PAT fallback.
Step 7 (Optional, Routed Mode Only) To use the interface IP address as a backup method when the other mapped
addresses are already allocated, check the Fall through to interface PAT (dest intf) check box, and choose
the interface from the drop-down list. To use the IPv6 address of the interface, also check the Use IPv6 for
click OK.
174
Dynamic PAT
Configure Dynamic Twice PAT (Hide)

This section describes how to configure twice NAT for dynamic PAT (hide), which uses a single address for
translation instead of a PAT pool.
Procedure
175
Dynamic PAT
interface.
Step 3 Choose Dynamic PAT (Hide) from the Action: Translated Packet > Source NAT Type drop-down list.
Note To configure dynamic PAT using a PAT pool, choose Dynamic instead of Dynamic PAT (Hide),
see Configure Dynamic Twice PAT Using a PAT Pool, on page 179.
a) For Match Criteria: Original Packet > Source Address, click the browse button and choose an existing
network object or group or create a new object or group from the Browse Original Source Address dialog
box. The group cannot contain both IPv4 and IPv6 addresses; it must contain one type only. The default
is any.
176
Dynamic PAT
b) (Optional) For Match Criteria: Original Packet > Destination Address, click the browse button and
choose an existing network object, group, or interface, or create a new object or group from the Browse
object that defines a host address, or an interface, or create a new object from the Browse Translated Source
Address dialog box.
If you want to use the IPv6 address of the interface, check the Use IPv6 for interface PAT check box.
b) (Optional.) For Action: Translated Packet > Destination Address, click the browse button and choose
an existing network object or group or create a new object or group from the Browse Translated Destination
Address dialog box. The group cannot contain both IPv4 and IPv6 addresses; it must contain one type
only.
mapped addresses.
if desired. For more information, see Static NAT, on page 187. See Guidelines for NAT, on page 154 for
information about disallowed mapped IP addresses.
177
Dynamic PAT
For example:
178
Dynamic PAT
Step 7 (Optional) Configure NAT options in the Options area.
• Enable rule—Enables this NAT rule. The rule is enabled by default.

Configure Dynamic Twice PAT Using a PAT Pool

This section describes how to configure twice NAT for dynamic PAT using a PAT pool.
Procedure
179
Dynamic PAT

interface.
Step 3 Choose Dynamic from the Action: Translated Packet > Source NAT Type drop-down list.
180
Dynamic PAT
a) For the Match Criteria: Original Packet > Source Address, click the browse button and choose an
existing network object or group or create a new object or group from the Browse Original Source Address
dialog box. The group cannot contain both IPv4 and IPv6 addresses; it must contain one type only. The
default is any.
b) (Optional.) For the Match Criteria: Original Packet > Destination Address, click the browse button
and choose an existing network object, group, or interface, or create a new object or group from the Browse
a) Check the PAT Pool Translated Address check box, then click the browse button and choose an existing
network object or group or create a new object or group from the Browse Translated PAT Pool Address
dialog box. Note: Leave the Source Address field empty.
181
Dynamic PAT
Note The object or group cannot contain a

subnet.
an existing network object or group, or create a new object or group from the Browse Translated Destination
Address dialog box.
mapped addresses.
For example:
182
Dynamic PAT
Step 7 (Optional.) For a PAT pool, configure the following options as needed:
• 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.
• Extend PAT uniqueness to per destination instead of per interface (8.4(3) and later, not including
8.5(1) or 8.6(1).)—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.
• Translate TCP or UDP ports into flat range (1024-65535) (8.4(3) and later, not including 8.5(1) or
8.6(1).)—To use the 1024 to 65535 port range as a single flat range when allocating ports. When choosing
the mapped port number for a translation, the ASA 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 range 1 to 1023 check box.
183
Dynamic PAT
• Enable Block Allocation (9.5.1 and later.)—Enables port block allocation. For carrier-grade or large-scale
PAT, you can allocate a block of ports for each host, rather than have NAT allocate one port translation
at a time. If you allocate a block of ports, subsequent connections from the host use new randomly-selected
ports within the block. If necessary, additional blocks are allocated if the host has active connections
for all ports in the original block. Port blocks are allocated in the 1024-65535 range only. Port block
allocation is compatible with round robin, but you cannot use it with the extended PAT or flat port range
options. You also cannot use interface PAT fallback.
Step 8 (Optional, Routed Mode Only.) To use the interface IP address as a backup method if the other mapped source
addresses are already allocated, check the Fall through to interface PAT check box. To use the IPv6 interface
address, also check the Use IPv6 for interface PAT check box.
The destination interface IP address is used. This option is only available if you configure a specific Destination
Interface.
• Enable rule—Enables this NAT rule. The rule is enabled by default.

184
Dynamic PAT
Configure PAT with Port Block Allocation

For carrier-grade or large-scale PAT, you can allocate a block of ports for each host, rather than have NAT
allocate one port translation at a time (see RFC 6888). If you allocate a block of ports, subsequent connections
from the host use new randomly-selected ports within the block. If necessary, additional blocks are allocated
if the host has active connections for all ports in the original block. Blocks are freed when the last xlate that
uses a port in the block is removed.
The main reason for allocating port blocks is reduced logging. The port block allocation is logged, connections
are logged, but xlates created within the port block are not logged. On the other hand, this makes log analysis
more difficult.
Port blocks are allocated in the 1024-65535 range only. Thus, if an application requires a low port number
(1-1023), it might not work. For example, an application requesting port 22 (SSH) will get a mapped port
within the range of 1024-65535 and within the block allocated to the host. You can create a separate NAT
rule that does not use block allocation for applications that use low port numbers; for twice NAT, ensure the
rule comes before the block allocation rule.
Before You Begin

Usage notes for NAT rules:
• You can include the Round Robin option, but you cannot include the options for extending PAT
uniqueness, using a flat range, or falling through to interface PAT. Other source/destination address and
port information is also allowed.
• As with all NAT changes, if you replace an existing rule, you must clear xlates related to the replaced
rule to have the new rule take effect. You can clear them explicitly or simply wait for them to time out.
• For a given PAT pool, you must specify (or not specify) block allocation for all rules that use the pool.
You cannot allocate blocks in one rule and not in another. PAT pools that overlap also cannot mix block
allocation settings. You also cannot overlap static NAT with port translation rules with the pool.
Procedure
Step 1 Select Configuration > Firewall > Advanced > PAT Port Block Allocation and configure the following
settings:
• Size of the block—The number of ports in each block. The range is 32-4096. The default is 512.
If you do not use the default, ensure that the size you choose divides evenly into 64,512 (the number of
ports in the 1024-65535 range). Otherwise, there will be ports that cannot be used. For example, if you
specify 100, there will be 12 unused ports.
• Maximum block allocation per host—The maximum number of blocks that can be allocated per host.
The limit is per protocol, so a limit of 4 means at most 4 UDP blocks, 4 TCP blocks, and 4 ICMP blocks
per host. The range is 1-8, the default is 4.
Step 2 Add NAT rules that use PAT pool block allocation.
a) Select Configuration > Firewall > NAT Rules.
b) Add or edit an object NAT or twice NAT rule.
c) Configure at least the following options:
185
Dynamic PAT
• (Twice NAT.) Select the object that defines the source address in Original Packet > Source Address.
• Type = Dynamic.
• Pat Pool Translated Address. Select a network object that defines the pat pool network.
• Enable Block Allocation.
d) Click OK.
Configure Per-Session PAT or Multi-Session PAT (Version 9.0(1) and Higher)

By default, all TCP PAT traffic and all UDP DNS traffic uses per-session PAT. To use multi-session PAT
for traffic, you can configure per-session PAT rules: a permit rule uses per-session PAT, and a deny rule uses
multi-session PAT.
Per-session PAT improves the scalability of PAT and, for clustering, allows each member unit to own PAT
connections; multi-session PAT connections have to be forwarded to and owned by the master unit. At the
end of a per-session PAT session, the ASA sends a reset and immediately removes the xlate. This reset causes
the end node to immediately release the connection, avoiding the TIME_WAIT state. Multi-session PAT, on
the other hand, uses the PAT timeout, by default 30 seconds.
For “hit-and-run” traffic, such as HTTP or HTTPS, per-session PAT can dramatically increase the connection
rate supported by one address. Without per-session PAT, the maximum connection rate for one address for
an IP protocol is approximately 2000 per second. With per-session PAT, the connection rate for one address
for an IP protocol is 65535/average-lifetime.
For traffic that can benefit from multi-session PAT, such as H.323, SIP, or Skinny, you can disable per-session
PAT by creating a per-session deny rule. These rules are available starting with version 9.0(1).
Before You Begin

By default, the following rules are installed:
• Permit TCP from any (IPv4 and IPv6) to any (IPv4 and IPv6).
• Permit UDP from any (IPv4 and IPv6) to the domain port.
These rules do not show up in the table.

You cannot remove these rules, and they always exist after any manually-created rules. Because rules are
evaluated in order, you can override the default rules. For example, to completely negate these rules, you
could add the following:
• Deny TCP from any (IPv4 and IPv6) to any (IPv4 and IPv6).
• Deny UDP from any (IPv4 and IPv6) to the domain port.
Procedure
Step 1 Choose Configuration > Firewall > Advanced > Per-Session NAT Rules.
186
Static NAT
• Choose Add > Add Per-Session NAT Rule.

• Select a rule and click Edit.
Step 3 Configure the rule:

• Action—Click Permit or Deny. A permit rule uses per-session PAT; a deny rule uses multi-session
PAT.
• Source—Specify the Source Address either by typing an address or clicking the ... button to choose an
object. For the service, select UDP or TCP. You can optionally specify a source port, although normally
you only specify the destination port. Either type in UDP/port or TCP/port, or click the ... button to
select a common value or object.
• Destination—Specify the Destination Address either by typing an address or clicking the ... button to
choose an object. For the service, select UDP or TCP; this must match the source service. You can
optionally specify a destination port. Either type in UDP/port or TCP/port, or click the ... button to select
a common value or object. You can use the operators != (not equal to), > (greater than), < (less than),
or specify a range using a hyphen, for example, 100-200.
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.
Figure 20: Static NAT
187
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 21: Typical Static NAT with Port Translation Scenario
Note For applications that require application inspection for secondary channels (for example, FTP and VoIP),
NAT automatically translates the secondary ports.
Following are some other uses of static NAT with port translation.
Static NAT with Identity Port Translation
You can simplify external access to internal resources. For example, if you have three separate servers
that provide services on different ports (such as FTP, HTTP, and SMTP), you can give external users
a single IP address to access those services. You can then configure static NAT with identity port
translation to map the single external IP address to the correct IP addresses of the real servers based on
the port they are trying to access. You do not need to change the port, because the servers are using the
standard ones (21, 80, and 25 respectively). For details on how to configure this example, see Single
Address for FTP, HTTP, and SMTP (Static NAT-with-Port-Translation), on page 220.
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.
188
Static NAT
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 22: One-to-Many Static NAT
189
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. For details on how to configure this example, see Inside Load Balancer with Multiple
Mapped Addresses (Static NAT, One-to-Many), on page 218.
Figure 23: 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.
190
Static NAT
The following figure shows a typical few-to-many static NAT scenario.
Figure 24: 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 25: 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 Network Object NAT or Static NAT-with-Port-Translation

This section describes how to configure a static NAT rule using network object NAT.
191
Static NAT
Procedure

• Name—The object name. Use characters a to z, A to Z, 0 to 9, a period, a dash, a comma, or an
underscore. The name must be 64 characters or less.
• Type—Host, Network, or Range.
• IP Addresses—IPv4 or IPv6 addresses, a single address for a host, a starting and ending address for a
Step 5 From the Type drop-down list, choose Static.
192
Static NAT
Step 6 In the Translated Addr. field, specify the mapped IP address as one of the following. 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. For more information, see Static NAT, on page 187.
• Type a host IP address. This provides a one-to-one mapping for host objects only. Otherwise, you get
a many-to-one mapping. For NAT46 or NAT66 translations, this can be an IPv6 network address.
• Click the browse button and select a network object (or create a new one). To do a one-to-one mapping
for a range of IP addresses, select an object that contains a range with the same number of addresses.
• (For static NAT-with-port-translation only; routed mode only.) Type an interface name or click the
browse button, and choose an interface from the Browse Translated Addr dialog box.
To use the IPv6 interface address, you must also check the Use IPv6 for interface PAT check box. Be
sure to also click Advanced and configure a service port translation. (You cannot specify an interface
in transparent mode.)
193
Static NAT
Step 7 (Optional.) For NAT46, check Use one-to-one address translation. For NAT 46, specify one-to-one 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 keyword.
click OK.
• Translate DNS replies for rule—Translates the IP address in DNS replies. Be sure DNS inspection is
enabled (it is enabled by default). See DNS and NAT, on page 250 for more information.
• Disable Proxy ARP on egress interface—Disables proxy ARP for incoming packets to the mapped IP
addresses. For information on the conditions which might require the disabling of proxy ARP, see
Mapped Addresses and Routing, on page 241.
• Service—Configures static NAT-with-port-translation. Choose the protocol, then enter the real port and
the mapped port. You can use port numbers or a well-known port name such as http.

Because static rules are bidirectional (allowing initiation to and from the real host), the NAT Rules table shows
two rows for each static rule, one for each direction.
Configure Static Twice NAT or Static NAT-with-Port-Translation

This section describes how to configure a static NAT rule using twice NAT.
Procedure
194
Static NAT

interface.
Step 3 Choose Static from the Action: Translated Packet > Source NAT Type drop-down list. Static is the default
setting.
195
Static NAT
is any, but do not use this option except for identity NAT.
b) (Optional) For Match Criteria: Original Packet > Destination Address, click the browse button and
Original Destination Address dialog box.
object or group or create a new object or group from the Browse Translated Source Address dialog box.
For static NAT, the mapping is typically one-to-one, so the real addresses have the same quantity as the
For static interface NAT with port translation, you can specify the interface instead of a network object/group
for the mapped address. If you want to use the IPv6 address of the interface, check the Use IPv6 for
196
Static NAT
For more information, see Static Interface NAT with Port Translation. See Guidelines for NAT, on page
154 for information about disallowed mapped IP addresses.
an existing network object or group, or create a new object or group from the Browse Translated Destination
Address dialog box.
Step 6 (Optional.) Identify the source or destination service ports for service translation.
• Identify the original packet source or destination port (the real source port or the mapped destination
port). For Match Criteria: Original Packet > Service, click the browse button and choose an existing
service object that specifies ports, or create a new object from the Browse Original Service dialog box.
• Identify the translated packet source or destination port (the mapped source port or the real destination
port). For Action: Translated Packet > Service, click the browse button and choose an existing service
object that specifies ports, or create a new object from the Browse Translated Service dialog box.
A service object can contain both a source and destination port. You should specify either the source or the
destination port for both the real and mapped service objects. You should only specify both the source and
destination ports if your application uses a fixed source port (such as some DNS servers); but fixed source
ports are rare. In the rare case where you specify both the source and destination ports in the object, the original
packet service object contains the real source port/mapped destination port; the translated packet service object
contains the mapped source port/real destination port. When translating a port, be sure the protocols in the
real and mapped service objects are identical (for example, both TCP). For identity NAT, you can use the
same service object for both the real and mapped ports. The “not equal” (!=) operator is not supported.
For example:
197
Static NAT
Step 7 (Optional.) For NAT46, check the Use one-to-one address translation check box. For NAT46, specify
one-to-one 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
keyword.
198
Identity NAT
• (For a source-only rule.) Translate DNS replies that match this rule—Rewrites the DNS A record in
DNS replies. Be sure DNS inspection is enabled (it is enabled by default). You cannot configure DNS
modification if you configure a destination address. See DNS and NAT, on page 250 for more information.
addresses. See Mapped Addresses and Routing, on page 241 for more information.
• Direction—To make the rule unidirectional, choose Unidirectional. The default is Both. Making the
rule unidirectional prevents destination addresses from initiating connections to the real addresses.
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. Identity NAT is necessary for remote access VPN,
where you need to exempt the client traffic from NAT.
The following figure shows a typical identity NAT scenario.
Figure 26: Identity NAT
The following topics explain how to configure identity NAT.
Configure Identity Network Object NAT

This section describes how to configure an identity NAT rule using network object NAT.
Procedure

199
Identity NAT
• Name—The object name. Use characters a to z, A to Z, 0 to 9, a period, a dash, a comma, or an
underscore. The name must be 64 characters or less.
• Type—Host, Network, or Range.
• IP Addresses—IPv4 or IPv6 addresses, a single address for a host, a starting and ending address for a
Step 5 From the Type drop-down list, choose Static.
Step 6 In the Translated Addr. field, do one of the following:

• Type the same IP address that you used for the real address. For identity NAT, this option works for
host objects only.
200
Identity NAT
• Click the browse button and select a network object (or create a new one). Use this option when
configuring identity NAT for a range of addresses.
click OK.
• Translate DNS replies for rule—Do not configure this option for identity NAT.
addresses. For information on the conditions which might require the disabling of proxy ARP, see
Mapped Addresses and Routing, on page 241.
• (Routed mode; interfaces specified.) Lookup route table to locate egress interface—Determines the
egress interface using a route lookup instead of using the interface specified in the NAT command. See
Determining the Egress Interface, on page 243 for more information.
• Service—Do not configure this option for identity NAT.

Because static rules are bidirectional (allowing initiation to and from the real host), the NAT Rules table shows
two rows for each static rule, one for each direction, unless you select the route lookup option.
Configure Identity Twice NAT

This section describes how to configure an identity NAT rule using twice NAT.
Procedure
201
Identity NAT

interface.
Step 3 Choose Static from the Action: Translated Packet > Source NAT Type drop-down list. Static is the default
setting.
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.
202
Identity NAT
is any; only use this option when also setting the mapped address to any.
b) (Optional.) For Match Criteria: Original Packet > Destination Address, click the browse button and
Original Destination Address dialog box.
For static interface NAT with port translation only, choose an interface. If you specify an interface, be
sure to also configure a a service translation. For more information, see Static Interface NAT with Port
Translation.
Step 5 Identify the translated packet addresses; namely, the packet addresses as they appear on the destination interface
network (the mapped source address and the real destination address).
a) For Action: Translated Packet > Source Address, click the browse button and choose the same network
object or group from the Browse Translated Source Address dialog box that you chose for the real source
address. Use any if you specified any for the real address.
b) For Match Criteria: Translated Packet > Destination Address, click the browse button and choose an
existing network object or group, or create a new object or group from the Browse Translated Destination
Address dialog box.
mapped addresses.
Step 6 (Optional.) Identify the source or destination service ports for service translation.
203
Identity NAT
• Identify the original packet source or destination port (the real source port or the mapped destination
port). For Match Criteria: Original Packet > Service, click the browse button and choose an existing
service object that specifies ports, or create a new object from the Browse Original Service dialog box.
• Identify the translated packet source or destination port (the mapped source port or the real destination
port). For Action: Translated Packet > Service, click the browse button and choose an existing service
object that specifies ports, or create a new object from the Browse Translated Service dialog box.
A service object can contain both a source and destination port. You should specify either the source or the
destination port for both the real and mapped service objects. You should only specify both the source and
destination ports if your application uses a fixed source port (such as some DNS servers); but fixed source
ports are rare. In the rare case where you specify both the source and destination ports in the object, the original
packet service object contains the real source port/mapped destination port; the translated packet service object
contains the mapped source port/real destination port. When translating a port, be sure the protocols in the
real and mapped service objects are identical (for example, both TCP). For identity NAT, you can use the
same service object for both the real and mapped ports. The “not equal” (!=) operator is not supported.
For example:
204
Identity NAT
Step 7 (Optional) Configure NAT options in the Options area.
• (For a source-only rule.) Translate DNS replies that match this rule—Although this option is available
if you do not configure a destination address, it is not applicable to identity NAT because you are
translating the address to itself, so the DNS reply does not need modification.
addresses. See Mapped Addresses and Routing, on page 241 for more information.
• (Routed mode; interfaces specified.) Lookup route table to locate egress interface—Determines the
egress interface using a route lookup instead of using the interface specified in the NAT command. See
Determining the Egress Interface, on page 243 for more information.
• Direction—To make the rule unidirectional, choose Unidirectional. The default is Both. Making the
rule unidirectional prevents traffic from initiating connections to the real addresses. You might want to
use this setting for testing purposes.
205
Monitoring NAT
Monitoring NAT
You can view NAT related graphs from the following pages:
• Monitoring > Properties > Connection Graphs > Xlates—Select the Xlate Utilization graph to view
the in-use and most-used xlates. This is equivalent to the show xlate command.
• Monitoring > Properties > Connection Graphs > Perfmon—Select the Xlate Perfmon graph to see
NAT performance information. This is equivalent to the xlate information from the show perfmon
command.
History for NAT

Platform
Network Object NAT 8.3(1) Configures NAT for a network object IP address(es).
Configuration > Firewall > NAT Rules Configuration >
Firewall > Objects > Network Objects/Groups
Twice NAT 8.3(1) Twice NAT lets you identify both the source and destination
address in a single rule.
We modified the following screen: Configuration > Firewall
> NAT Rules.
206
History for NAT
Platform
Identity NAT configurable proxy ARP and route 8.4(2)/8.5(1) In earlier releases for identity NAT, proxy ARP was disabled,
lookup and a route lookup was always used to determine the egress
interface. You could not configure these settings. In 8.4(2) and
later, the default behavior for identity NAT was changed to
match the behavior of other static NAT configurations: proxy
ARP is enabled, and the NAT configuration determines the
egress interface (if specified) by default. You can leave these
settings as is, or you can enable or disable them discretely.
Note that you can now also disable proxy ARP for regular
static NAT.
For pre-8.3 configurations, the migration of NAT exempt rules
(the nat 0 access-list command) to 8.4(2) and later now
includes the following keywords to disable proxy ARP and to
use a route lookup: no-proxy-arp and route-lookup. The
unidirectional keyword that was used for migrating to 8.3(2)
and 8.4(1) is no longer used for migration. When upgrading
to 8.4(2) from 8.3(1), 8.3(2), and 8.4(1), all identity NAT
configurations will now include the no-proxy-arp and
route-lookup keywords, to maintain existing functionality.
The unidirectional keyword is removed.
We modified the following screens: Configuration > Firewall
> NAT Rules > Add/Edit Network Object > Advanced NAT
Settings; Configuration > Firewall > NAT Rules > Add/Edit
NAT Rule.
PAT pool and round robin address assignment 8.4(2)/8.5(1) You can now specify a pool of PAT addresses instead of a
single address. You can also optionally enable round-robin
assignment of PAT addresses instead of first using all ports
on a PAT address before using the next address in the pool.
These features help prevent a large number of connections
from a single PAT address from appearing to be part of a DoS
attack and makes configuration of large numbers of PAT
addresses easy.
> NAT Rules > Add/Edit Network Object; Configuration >
Firewall > NAT Rules > Add/Edit NAT Rule.
Round robin PAT pool allocation uses the same 8.4(3) When using a PAT pool with round robin allocation, if a host
IP address for existing hosts has an existing connection, then subsequent connections from
that host will use the same PAT IP address if ports are
available.
We did not modify any screens.
This feature is not available in 8.5(1) or 8.6(1).
207
History for NAT
Platform
Flat range of PAT ports for a PAT pool 8.4(3) 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.
If you have a lot of traffic that uses the lower port ranges, when
using a PAT pool, you can now specify a flat range of ports
to be used instead of the three unequal-sized tiers: either 1024
to 65535, or 1 to 65535.
Extended PAT for a PAT pool 8.4(3) Each PAT IP address allows up to 65535 ports. If 65535 ports
do not provide enough translations, you can now enable
extended PAT for a PAT pool. Extended PAT uses 65535 ports
per service, as opposed to per IP address, by including the
destination address and port in the translation information.
208
History for NAT
Platform
Automatic NAT rules to translate a VPN peer’s 8.4(3) In rare situations, you might want to use a VPN peer’s real IP
local IP address back to the peer’s real IP address address on the inside network instead of an assigned local IP
address. Normally with VPN, the peer is given an assigned
local IP address to access the inside network. However, you
might want to translate the local IP address back to the peer’s
real public IP address if, for example, your inside servers and
network security is based on the peer’s real IP address.
You can enable this feature on one interface per tunnel group.
Object NAT rules are dynamically added and deleted when
the VPN session is established or disconnected. You can view
the rules using the show nat command.
Because of routing issues, we do not recommend using this
feature unless you know you need it; contact Cisco TAC to
confirm feature compatibility with your network. See the
following limitations:
• Only supports Cisco IPsec and AnyConnect Client.
• Return traffic to the public IP addresses must be routed
back to the ASA so the NAT policy and VPN policy can
be applied.
• Does not support load-balancing (because of routing
issues).
• Does not support roaming (public IP changing).
ASDM does not support this command; enter the command

using the Command Line Tool.
NAT support for IPv6 9.0(1) NAT now supports IPv6 traffic, as well as translating between
IPv4 and IPv6. Translating between IPv4 and IPv6 is not
supported in transparent mode.
> Objects > Network Objects/Group; Configuration > Firewall
> NAT Rules.
NAT support for reverse DNS lookups 9.0(1) NAT now supports translation of the DNS PTR record for
reverse DNS lookups when using IPv4 NAT, IPv6 NAT, and
NAT64 with DNS inspection enabled for the NAT rule.
209
History for NAT
Platform
Per-session PAT 9.0(1) The per-session PAT feature improves the scalability of PAT
and, for clustering, allows each member unit to own PAT
connections; multi-session PAT connections have to be
forwarded to and owned by the master unit. At the end of a
per-session PAT session, the ASA sends a reset and
immediately removes the xlate. This reset causes the end node
to immediately release the connection, avoiding the
TIME_WAIT state. Multi-session PAT, on the other hand,
uses the PAT timeout, by default 30 seconds. For “hit-and-run”
traffic, such as HTTP or HTTPS, the per-session feature can
dramatically increase the connection rate supported by one
address. Without the per-session feature, the maximum
connection rate for one address for an IP protocol is
approximately 2000 per second. With the per-session feature,
the connection rate for one address for an IP protocol is
65535/average-lifetime.
By default, all TCP traffic and UDP DNS traffic use a
per-session PAT xlate. For traffic that requires multi-session
PAT, such as H.323, SIP, or Skinny, you can disable
per-session PAT by creating a per-session deny rule.
We introduced the following screen: Configuration > Firewall
> Advanced > Per-Session NAT Rules.
Transactional Commit Model on NAT Rule 9.3(1) When enabled, a NAT rule update is applied after the rule
Engine compilation is completed; without affecting the rule matching
performance.
We added NAT to the following screen: Configuration >
Device Management > Advanced > Rule Engine.
Carrier Grade NAT enhancements 9.5(1) For carrier-grade or large-scale PAT, you can allocate a block
of ports for each host, rather than have NAT allocate one port
translation at a time (see RFC 6888).
We added the following command: Configuration > Firewall
> Advanced > PAT Port Block Allocation. We added Enable
Block Allocation the object NAT and twice NAT dialog boxes.
NAT support for SCTP 9.5(2) You can now specify SCTP ports in static network object NAT
rules. Using SCTP in static twice NAT is not recommended.
Dynamic NAT/PAT does not support SCTP.
> NAT add/edit static network object NAT rule, Advanced
NAT Settings dialog box.
210
CHAPTER 10
NAT Examples and Reference
The following topics provide examples for configuring NAT, plus information on advanced configuration
and troubleshooting.
• Examples for Network Object NAT, page 211

• Examples for Twice NAT, page 224
• NAT in Routed and Transparent Mode, page 238
• Routing NAT Packets, page 241
• NAT for VPN, page 244
• DNS and NAT, page 250
Examples for Network Object NAT

Following are some configuration examples for network object NAT.
211
Providing Access to an Inside Web Server (Static NAT)

The following example performs static NAT for an inside web server. The real address is on a private network,
so a public address is required. Static NAT is necessary so hosts can initiate traffic to the web server at a fixed
address.
Figure 27: Static NAT for an Inside Web Server
Procedure
Step 1 Choose Configuration > Firewall > NAT.

Step 2 Choose Add > Network Object NAT Rule, name the new network object and define the web server host
address.
Step 3 Configure static NAT for the object.
212
Step 4 Click Advanced and configure the real and mapped interfaces.
Step 5 Click OK to return to the Edit Network Object dialog box, click OK again, and then click Apply.
213
NAT for Inside Hosts (Dynamic NAT) and NAT for an Outside Web Server (Static NAT)
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 28: Dynamic NAT for Inside, Static NAT for Outside Web Server
Procedure

Step 2 Choose Add > Network Object NAT Rule, name the new network object and define the inside network.
Step 3 Enable dynamic NAT for the inside network.
214
Step 4 For the Translated Addr field, add a new network object for the dynamic NAT pool to which you want to
translate the inside addresses by clicking the browse button.
a) Choose Add > Network Object, name the new object, define the range of addresses in the NAT pool,
and click OK.
b) Choose the new network object by double-clicking it. Click OK to return to the NAT configuration.
215
Step 6 Click OK to return to the Edit Network Object dialog box, click then click OK again to return to the NAT
Rules table.
Step 7 Choose Add > Network Object NAT Rule and create an object for the outside web server.
Step 8 Configure static NAT for the web server.
216
217
Inside Load Balancer with Multiple Mapped Addresses (Static NAT, One-to-Many)
The following example shows an inside load balancer that is translated to multiple IP addresses. When an
outside host accesses one of the mapped IP addresses, it is untranslated to the single load balancer address.
Depending on the URL requested, it redirects traffic to the correct web server.
Figure 29: Static NAT with One-to-Many for an Inside Load Balancer
Procedure

Step 2 Choose Add > Network Object NAT Rule, name the new network object and define the load balancer
address.
218
Step 3 Enable static NAT for the load balancer:
Step 4 For the Translated Addr field, add a new network object for the static NAT group of addresses to which you
want to translate the load balancer address by clicking the browse button.
a) Choose Add > Network Object, name the new object, define the range of addresses, and click OK.
b) Choose the new network object by double-clicking it. Click OK to return to the NAT configuration.
219
Single Address for FTP, HTTP, and SMTP (Static NAT-with-Port-Translation)

The following static NAT-with-port-translation example provides a single address for remote users to access
FTP, HTTP, and SMTP. These servers are actually different devices on the real network, but for each server,
220
you can specify static NAT-with-port-translation rules that use the same mapped IP address, but different
ports.
Figure 30: Static NAT-with-Port-Translation
Procedure

Step 2 Configure the static network object NAT with port translation rule for the FTP server.
a) Choose Add > Network Object NAT Rule.
b) Name the new network object, define the FTP server address, enable static NAT, and enter the translated
address.
221
c) Click Advanced and configure the real and mapped interfaces and port translation for FTP, mapping the
FTP port to itself.
d) Click OK, then OK again to save the rule and return to the NAT page.
Step 3 Configure the static network object NAT with port translation rule for the HTTP server.
b) Name the new network object, define the HTTP server address, enable static NAT, and enter the translated
address.
222
c) Click Advanced and configure the real and mapped interfaces and port translation for HTTP, mapping
the HTTP port to itself.
d) Click OK, then OK again to save the rule and return to the NAT page.
Step 4 Configure the static network object NAT with port translation rule for the SMTP server.
b) Name the new network object, define the SMTP server address, enable static NAT, and enter the translated
address.
223
Examples for Twice NAT
c) Click Advanced and configure the real and mapped interfaces and port translation for SMTP, mapping
the SMTP port to itself.
d) Click OK to return to the Edit Network Object dialog box, click OK again, and then click Apply.

This section includes the following configuration examples:
224
Different Translation Depending on the Destination (Dynamic Twice PAT)

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 31: Twice NAT with Different Destination Addresses
Procedure
Step 1 On the Configuration > Firewall > NAT Rules page, click Add > Add NAT Rule Before Network
Object NAT Rules to add a NAT rule for traffic from the inside network to DMZ network 1.
If you want to add a NAT rule to section 3, after the network object NAT rules, choose Add NAT Rule After
Network Object NAT Rules.
225
Step 3 For the Original Source Address, click the browse button to add a new network object for the inside network
in the Browse Original Source Address dialog box.
a) Select Add > Network Object.
b) Define the inside network addresses, and click OK.
c) Choose the new network object by double-clicking it. Click OK to return to the NAT configuration.
226
Step 4 For the Original Destination Address, click the browse button to add a new network object for DMZ network
1 in the Browse Original Destination Address dialog box.
b) Define the DMZ network 1 addresses, and click OK.
Step 5 Set the NAT Type to Dynamic PAT (Hide):
Step 6 For the Translated Source Address, click the browse button to add a new network object for the PAT address
in the Browse Translated Source Address dialog box.
b) Define the PAT address, and click OK.
227
Step 7 For the Translated Destination Address, type the name of the Original Destination Address (DMZnetwork1)
or click the browse button to choose it.
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.
Step 8 Click OK to add the rule to the NAT table.

Step 9 Click Add > Add NAT Rule Before Network Object NAT Rules or Add NAT Rule After Network
Object NAT Rules to add a NAT rule for traffic from the inside network to DMZ network 2.
228
Step 11 For the Original Source Address, type the name of the inside network object (myInsideNetwork) or click the
browse button to choose it.
Step 12 For the Original Destination Address, click the browse button to add a new network object for DMZ network
2 in the Browse Original Destination Address dialog box.
b) Define the DMZ network 2 addresses, and click OK.
229
Step 15 For the Translated Destination Address, type the name of the Original Destination Address (DMZnetwork2)

230
Different Translation Depending on the Destination Address and Port (Dynamic PAT)
The following figure shows the use of source and destination ports. The host on the 10.1.2.0/24 network
accesses a single host for both web services and Telnet services. When the host accesses the server for Telnet
services, the real address is translated to 209.165.202.129:port. When the host accesses the same server for
web services, the real address is translated to 209.165.202.130:port.
Figure 32: Twice NAT with Different Destination Ports
Procedure
Step 1 On the Configuration > Firewall > NAT Rules page, click Add > Add NAT Rule Before Network
Object NAT Rules to add a NAT rule for traffic from the inside network to the Telnet server.
If you want to add a NAT rule to section 3, after the network object NAT rules, choose Add NAT Rule After
Network Object NAT Rules.
231
Step 3 For the Original Source Address, click the browse button to add a new network object for the inside network
in the Browse Original Source Address dialog box.
b) Define the inside network addresses, and click OK.
232
Step 4 For the Original Destination Address, click the browse button to add a new network object for the Telnet/Web
server in the Browse Original Destination Address dialog box.
b) Define the server address, and click OK.
Step 5 For the Original Service, click the browse button to add a new service object for Telnet in the Browse Original
Service dialog box.
a) Select Add > Service Object.
b) Define the protocol and port, and click OK.
c) Choose the new service object by double-clicking it. Click OK to return to the NAT configuration.
233
Step 8 For the Translated Destination Address, type the name of the Original Destination Address (TelnetWebServer)
234

Step 10 Click Add > Add NAT Rule Before Network Object NAT Rules or Add NAT Rule After Network
Object NAT Rules to add a NAT rule for traffic from the inside network to the web server.
Step 11 Set the real and mapped interfaces.
Step 12 For the Original Source Address, type the name of the inside network object (myInsideNetwork) or click the
browse button to choose it.
Step 13 For the Original Destination Address, type the name of the Telnet/web server network object (TelnetWebServer)
Step 14 For the Original Service, click the browse button to add a new service object for HTTP in the Browse Original
Service dialog box.
a) Select Add > Service Object.
b) Define the protocol and port, and click OK.
235
c) Choose the new service object by double-clicking it. Click OK to return to the NAT configuration.
Step 17 For the Translated Destination Address, type the name of the Original Destination Address (TelnetWebServer)
236

Example: Twice NAT with Destination Address Translation

The following figure shows a remote host connecting to a mapped host. The mapped host has a twice static
NAT translation that translates the real address only for traffic to and from the 209.165.201.0/27 network. A
237
NAT in Routed and Transparent Mode
translation does not exist for the 209.165.200.224/27 network, so the translated host cannot connect to that
network, nor can a host on that network connect to the translated host.
Figure 33: Twice Static NAT with Destination Address Translation

You can configure NAT in both routed and transparent firewall mode. The following sections describe typical
usage for each firewall mode.
238
NAT in Routed Mode

The following figure shows a typical NAT example in routed mode, with a private network on the inside.
Figure 34: 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 ASA
receives the packet because the ASA performs proxy ARP to claim the packet.
3 The ASA 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

Using NAT in transparent mode eliminates the need for the upstream or downstream routers to perform NAT
for their networks.
NAT in transparent mode has the following requirements and limitations:
• Because the transparent firewall does not have any interface IP addresses, you cannot use interface PAT.
• ARP inspection is not supported. Moreover, if for some reason a host on one side of the ASA sends an
ARP request to a host on the other side of the ASA, 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.
239
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 35: NAT Example: Transparent Mode
1 When the inside host at 10.1.1.75 sends a packet to a web server, the real source address of the packet,
10.1.1.75, is changed to a mapped address, 209.165.201.15.
2 When the server responds, it sends the response to the mapped address, 209.165.201.15, and the ASA
receives the packet because the upstream router includes this mapped network in a static route directed to
the ASA management IP address.
3 The ASA 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 ASA sends it directly to the host.
4 For host 192.168.1.2, the same process occurs, except for returning traffic, the ASA looks up the route in
its routing table and sends the packet to the downstream router at 10.1.1.3 based on the ASA static route
for 192.168.1.0/24.
240
Routing NAT Packets
Routing NAT Packets

The ASA needs to be the destination for any packets sent to the mapped address. The ASA also needs to
determine the egress interface for any packets it receives destined for mapped addresses. This section describes
how the ASA handles accepting and delivering packets with NAT.
Mapped Addresses and Routing

When you translate the real address to a mapped address, the mapped address you choose determines how to
configure routing, if necessary, for the mapped address.
See additional guidelines about mapped IP addresses in Additional Guidelines for NAT, on page 156.
The following topics explain the mapped address types.
Addresses on the Same Network as the Mapped Interface

If you use addresses on the same network as the destination (mapped) interface, the ASA 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 ASA does not have to be the gateway for any additional networks.
This solution is ideal if the outside network contains an adequate number of free addresses, a consideration
if you are using a 1:1 translation like dynamic NAT or static NAT. Dynamic PAT greatly extends the number
of translations you can use with a small number of addresses, so even if the available addresses on the outside
network is small, this method can be used. For PAT, you can even use the IP address of the mapped interface.
Note If you configure the mapped interface to be any interface, and you specify a mapped address on the same
network as one of the mapped interfaces, then if an ARP request for that mapped address comes in on a
different interface, then you need to manually configure an ARP entry for that network on the ingress
interface, specifying its MAC address. Typically, if you specify any interface for the mapped interface,
then you use a unique network for the mapped addresses, so this situation would not occur. Select
Configuration > Device Management > Advanced > ARP > ARP Static Table to configure ARP.
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 ASA.
Alternatively for routed mode, you can configure a static route on the ASA 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.
route inside 209.165.201.5 255.255.255.255 10.1.1.99
For transparent mode, if the real host is directly-connected, configure the static route on the upstream router
to point to the ASA: in 8.3, specify the global management IP address; in 8.4(1) and later, specify the bridge
241
Routing NAT Packets
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)

(8.3(1), 8.3(2), and 8.4(1)) The default behavior for identity NAT has proxy ARP disabled. You cannot
configure this setting.
(8.4(2) and later) 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 ASA will then proxy ARP for
the address, even though the packet is not actually destined for the ASA. (Note that this problem occurs even
if you have a twice 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 ASA ARP response is received before
the actual host ARP response, then traffic will be mistakenly sent to the ASA.
Figure 36: Proxy ARP Problems with Identity NAT
In rare cases, you need proxy ARP for identity NAT; for example for virtual Telnet. When using AAA for
network access, a host needs to authenticate with the ASA using a service like Telnet before any other traffic
can pass. You can configure a virtual Telnet server on the ASA to provide the necessary login. When accessing
the virtual Telnet address from the outside, you must configure an identity NAT rule for the address specifically
for the proxy ARP functionality. Due to internal processes for virtual Telnet, proxy ARP lets the ASA keep
242
Routing NAT Packets
traffic destined for the virtual Telnet address rather than send the traffic out the source interface according to
the NAT rule. (See the following figure).
Figure 37: Proxy ARP and Virtual Telnet
Transparent Mode Routing Requirements for Remote Networks

When you use NAT in transparent mode, some types of traffic require static routes. See the general operations
configuration guide for more information.
Determining the Egress Interface

When you use NAT and the ASA receives traffic for a mapped address, then the ASA untranslates the
destination address according to the NAT rule, and then it sends the packet on to the real address. The ASA
determines the egress interface for the packet in the following ways:
• Transparent mode—The ASA determines the egress interface for the real address by using the NAT
rule; you must specify the source and destination interfaces as part of the NAT rule.
• Routed mode—The ASA determines the egress interface in one of the following ways:
◦You configure the interface in the NAT rule—The ASA uses the NAT rule to determine the egress
interface. However, you have the option to always use a route lookup instead. In certain scenarios,
a route lookup override is required.
◦You do not configure the interface in the NAT rule—The ASA uses a route lookup to determine
the egress interface.
243
NAT for VPN
The following figure shows the egress interface selection method in routed mode. In almost all cases, a route
lookup is equivalent to the NAT rule interface, but in some configurations, the two methods might differ.
Figure 38: Routed Mode Egress Interface Selection with NAT
NAT for VPN

The following topics explain NAT usage with the various types of VPN.
NAT and Remote Access VPN

The following figure shows both an inside server (10.1.1.6) and a VPN client (209.165.201.10) accessing the
Internet. Unless you configure split tunneling for the VPN client (where only specified traffic goes through
the VPN tunnel), then Internet-bound VPN traffic must also go through the ASA. When the VPN traffic enters
the ASA, the ASA decrypts the packet; the resulting packet includes the VPN client local address (10.3.3.10)
as the source. For both inside and VPN client local networks, you need a public IP address provided by NAT
244
NAT for VPN
to access the Internet. The below example uses interface PAT rules. To allow the VPN traffic to exit the same
interface it entered, you also need to enable intra-interface communication (also known as “hairpin” networking).
Figure 39: Interface PAT for Internet-Bound VPN Traffic (Intra-Interface)
The following figure shows a VPN client that wants to access an inside mail server. Because the ASA expects
traffic between the inside network and any outside network to match the interface PAT rule you set up for
Internet access, traffic from the VPN client (10.3.3.10) to the SMTP server (10.1.1.6) will be dropped due to
a reverse path failure: traffic from 10.3.3.10 to 10.1.1.6 does not match a NAT rule, but returning traffic from
10.1.1.6 to 10.3.3.10 should match the interface PAT rule for outgoing traffic. Because forward and reverse
flows do not match, the ASA drops the packet when it is received. To avoid this failure, you need to exempt
245
NAT for VPN
the inside-to-VPN client traffic from the interface PAT rule by using an identity NAT rule between those
networks. Identity NAT simply translates an address to the same address.
Figure 40: Identity NAT for VPN Clients
See the following sample NAT configuration for the above network:
! Enable hairpin for non-split-tunneled VPN client traffic:

same-security-traffic permit intra-interface
! Identify local VPN network, & perform object interface PAT when going to Internet:
object network vpn_local
subnet 10.3.3.0 255.255.255.0
nat (outside,outside) dynamic interface
! Identify inside network, & perform object interface PAT when going to Internet:
object network inside_nw
subnet 10.1.1.0 255.255.255.0
nat (inside,outside) dynamic interface
! Use twice NAT to pass traffic between the inside network and the VPN client without
! address translation (identity NAT):
nat (inside,outside) source static inside_nw inside_nw destination static vpn_local vpn_local
NAT and Site-to-Site VPN

The following figure shows a site-to-site tunnel connecting the Boulder and San Jose offices. For traffic that
you want to go to the Internet (for example from 10.1.1.6 in Boulder to www.example.com), you need a public
IP address provided by NAT to access the Internet. The below example uses interface PAT rules. However,
for traffic that you want to go over the VPN tunnel (for example from 10.1.1.6 in Boulder to 10.2.2.78 in San
246
NAT for VPN
Jose), you do not want to perform NAT; you need to exempt that traffic by creating an identity NAT rule.
Identity NAT simply translates an address to the same address.
Figure 41: Interface PAT and Identity NAT for Site-to-Site VPN
The following figure shows a VPN client connected to Firewall1 (Boulder), with a Telnet request for a server
(10.2.2.78) accessible over a site-to-site tunnel between Firewall1 and Firewall2 (San Jose). You also need
to configure identity NAT between the VPN client and the Boulder & San Jose networks, just as you would
between any networks connected by VPN to exempt this traffic from outbound NAT rules.
Figure 42: VPN Client Access to Site-to-Site VPN
247
NAT for VPN
See the following sample NAT configuration for Firewall1 (Boulder):
! Enable hairpin for VPN client traffic:

subnet 10.3.3.0 255.255.255.0
! Identify inside Boulder network, & perform object interface PAT when going to Internet:
object network boulder_inside
subnet 10.1.1.0 255.255.255.0
! Identify inside San Jose network for use in twice NAT rule:
object network sanjose_inside
subnet 10.2.2.0 255.255.255.0
! Use twice NAT to pass traffic between the Boulder network and the VPN client without
nat (inside,outside) source static boulder_inside boulder_inside
destination static vpn_local vpn_local
! Use twice NAT to pass traffic between the Boulder network and San Jose without
nat (inside,outside) source static boulder_inside boulder_inside
destination static sanjose_inside sanjose_inside
! Use twice NAT to pass traffic between the VPN client and San Jose without
nat (outside,outside) source static vpn_local vpn_local
destination static sanjose_inside sanjose_inside
See the following sample NAT configuration for Firewall2 (San Jose):
! Identify inside San Jose network, & perform object interface PAT when going to Internet:
object network sanjose_inside
subnet 10.2.2.0 255.255.255.0
! Identify inside Boulder network for use in twice NAT rule:

object network boulder_inside
subnet 10.1.1.0 255.255.255.0
! Identify local VPN network for use in twice NAT rule:

subnet 10.3.3.0 255.255.255.0
! Use twice NAT to pass traffic between the San Jose network and Boulder without
nat (inside,outside) source static sanjose_inside sanjose_inside
destination static boulder_inside boulder_inside
! Use twice NAT to pass traffic between the San Jose network and the VPN client without
nat (inside,outside) source static sanjose_inside sanjose_inside
destination static vpn_local vpn_local
NAT and VPN Management Access

When using VPN, you can allow management access to an interface other than the one from which you entered
the ASA. For example, if you enter the ASA from the outside interface, the management-access feature lets
you connect to the inside interface using ASDM, SSH, Telnet, or SNMP; or you can ping the inside interface.
248
NAT for VPN
The following figure shows a VPN client Telnetting to the ASA inside interface. When you use a
management-access interface, and you configure identity NAT according to NAT and Remote Access VPN,
on page 244 or NAT and Site-to-Site VPN, on page 246, you must configure NAT with the route lookup option.
Without route lookup, the ASA sends traffic out the interface specified in the NAT command, regardless of
what the routing table says; in the below example, the egress interface is the inside interface. You do not want
the ASA to send the management traffic out to the inside network; it will never return to the inside interface
IP address. The route lookup option lets the ASA send the traffic directly to the inside interface IP address
instead of to the inside network. For traffic from the VPN client to a host on the inside network, the route
lookup option will still result in the correct egress interface (inside), so normal traffic flow is not affected.
See the Determining the Egress Interface, on page 243 for more information about the route lookup option.
Figure 43: VPN Management Access
See the following sample NAT configuration for the above network:
! Enable hairpin for non-split-tunneled VPN client traffic:

! Enable management access on inside ifc:

management-access inside
subnet 10.3.3.0 255.255.255.0
! Identify inside network, & perform object interface PAT when going to Internet:
object network inside_nw
subnet 10.1.1.0 255.255.255.0
249
DNS and NAT
! Use twice NAT to pass traffic between the inside network and the VPN client without
! address translation (identity NAT), w/route-lookup:
nat (outside,inside) source static vpn_local vpn_local
destination static inside_nw inside_nw route-lookup
Troubleshooting NAT and VPN

See the following monitoring tools for troubleshooting NAT issues with VPN:
• Packet tracer—When used correctly, a packet tracer shows which NAT rules a packet is hitting.
• show nat detail—Shows hit counts and untranslated traffic for a given NAT rule.
• show conn all—Lets you see active connections including to and from the box traffic.
To familiarize yourself with a non-working configuration vs. a working configuration, you can perform the
following steps:
1 Configure VPN without identity NAT.
2 Enter show nat detail and show conn all.
3 Add the identity NAT configuration.
4 Repeat show nat detail and show conn all.
DNS and NAT

You might need to configure the ASA 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.
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 some limitations with DNS rewrite:
• DNS rewrite is not applicable for PAT because multiple PAT rules are applicable for each A-record,
and the PAT rule to use is ambiguous.
• If you configure a twice NAT rule, you cannot configure DNS modification if you specify the source
address as well as the destination address. These kinds of rules can potentially have a different translation
for a single address when going to A vs. B. Therefore, the ASA 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.
• DNS rewrite requires DNS application inspection to be enabled, which it is on by default.
• 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.
250
DNS and NAT
DNS Reply Modification, DNS Server on Outside

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 the ASA 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 ASA 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.
Figure 44: DNS Reply Modification, DNS Server on Outside
251
DNS and NAT
Procedure

Step 2 Choose Add > Network Object NAT Rule.
Step 3 Name the new network object, define the FTP server address, enable static NAT and enter the translated
address.
Step 4 Click Advanced and configure the real and mapped interfaces and DNS modification.
252
DNS and NAT
DNS Reply Modification, DNS Server, Host, and Server on Separate Networks
The following figure shows a user on the inside network requesting the IP address for ftp.cisco.com, which
is on the DMZ network, from an outside DNS server. The DNS server replies with the mapped address
(209.165.201.10) according to the static rule between outside and DMZ even though the user is not on the
DMZ network. The ASA translates the address inside the DNS reply to 10.1.3.14.
If the user needs to access ftp.cisco.com using the real address, then no further configuration is required. If
there is also a static rule between the inside and DMZ, then you also need to enable DNS reply modification
on this rule. The DNS reply will then be modified two times.In this case, the ASA again translates the address
inside the DNS reply to 192.168.1.10 according to the static rule between inside and DMZ.
Figure 45: DNS Reply Modification, DNS Server, Host, and Server on Separate Networks
DNS Reply Modification, DNS Server on Host Network

The following figure shows an FTP server and DNS server on the outside. The ASA 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
253
DNS and NAT
the mapped address for ftp.cisco.com (10.1.2.56) you need to configure DNS reply modification for the static
translation.
Figure 46: DNS Reply Modification, DNS Server on Host Network
Procedure

Step 2 Choose Add > Network Object NAT Rule.
Step 3 Name the new network object, define the FTP server address, enable static NAT and enter the translated
address.
254
DNS and NAT
Step 4 Click Advanced and configure the real and mapped interfaces and DNS modification.
DNS64 Reply Modification Using Outside NAT

The following figure shows an FTP server and DNS server on the outside IPv4 network. The ASA 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.
255
DNS and NAT
Because you want inside users to use the mapped address for ftp.cisco.com (2001:DB8::D1A5:C8E1) 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.
Figure 47: DNS64 Reply Modification Using Outside NAT
Procedure

Step 2 Configure static network object NAT with DNS modification for the FTP server.
b) Name the new network object, define the FTP server address, enable static NAT, and enter the translated
address. Because this is a one-to-one translation for NAT46, select Use one-to-one address translation.
256
DNS and NAT
c) Click Advanced to configure the real and mapped interfaces and DNS modification.
257
DNS and NAT
d) Click OK to return to the Network Object dialog box, and click OK again to save the rule.
Step 3 Configure static network object NAT for the DNS server.
b) Name the new network object, define the DNS server address, enable static NAT, and enter the translated
address. Because this is a one-to-one translation for NAT46, select Use one-to-one address translation.
c) Click Advanced to configure the real and mapped interfaces.
258
DNS and NAT
d) Click OK to return to the Network Object dialog box, and click OK again to save the rule.
Step 4 Configure PAT for the inside IPv6 network.
b) Name the new network object, define the IPv6 network address, and select Dynamic NAT.
c) Select PAT Pool Translated Address, and click the ... (browse) button to create the PAT pool object.
d) In the Browse PAT Pool Translated Address dialog box, select Add > Network Object. Name the new
object, enter the address range for the PAT pool, and click OK.
e) In the Browse PAT Pool Translated Address dialog box, double-click the PAT pool object you created to
select it and click OK.
259
DNS and NAT
f) Click Advanced to configure the real and mapped interfaces.
g) Click OK to return to the Network Object dialog box.
260
DNS and NAT
Step 5 Click OK, and then click Apply.
PTR Modification, DNS Server on Host Network

The following figure shows an FTP server and DNS server on the outside. The ASA has a static translation
for the outside server. In this case, when an inside user performs a reverse DNS lookup for 10.1.2.56, the
261
DNS and NAT
ASA modifies the reverse DNS query with the real address, and the DNS server responds with the server
name, ftp.cisco.com.
Figure 48: PTR Modification, DNS Server on Host Network
262
PART III
Service Policies and Application Inspection
• Service Policy, page 265
• Getting Started with Application Layer Protocol Inspection, page 281
• Inspection of Basic Internet Protocols, page 299
• Inspection for Voice and Video Protocols, page 331
• Inspection for Mobile Networks, page 351
CHAPTER 11
Service Policy
Service policies provide a consistent and flexible way to configure ASA features. 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 Service Policies, page 265

• Guidelines for Service Policies, page 271
• Defaults for Service Policies, page 272
• Configure Service Policies, page 274
• History for Service Policies, page 280
About Service Policies

The following topics describe how service policies work.
The Components of a Service Policy

The point of service policies is to apply advanced services to the traffic you are allowing. Any traffic permitted
by access rules can have service policies applied, and thus receive special processing, such as being redirected
to a service module or having application inspection applied.
You can have these types of service policy:
• One global policy that gets applied to all interfaces.
• One service policy applied per interface. The policy can be a mix of classes for traffic going through
the device and management traffic directed at the ASA interface rather than going through it,
Each service policy is composed of the following elements:

1 Service policy map, which is the ordered set of rules, and is named on the service-policy command. In
ASDM, the policy map is represented as a folder on the Service Policy Rules page.
265
2 Rules, each rule being a class command within the service policy map and the commands associated with
the class command. In ASDM, each rule is shown on a separate row, and the name of the rule is the class
name.
The class command defines the traffic matching criteria for the rule.
The commands associated with class, such as inspect, set connection timeout, and so forth, define the
services and constraints to apply to matching traffic. Note that inspect commands can point to inspection
policy maps, which define actions to apply to inspected traffic. Keep in mind that inspection policy maps
are not the same as service policy maps.
The following example compares how service policies appear in the CLI with how they appear in ASDM.
Note that there is not a one-to-one mapping between the figure call-outs and lines in the CLI.
The following CLI is generated by the rules shown in the figure above.
: Access lists used in class maps.

: In ASDM, these map to call-out 3, from the Match to the Time fields.
access-list inside_mpc line 1 extended permit tcp 10.100.10.0 255.255.255.0 any eq sip
access-list inside_mpc_1 line 1 extended deny udp host 10.1.1.15 any eq snmp
access-list inside_mpc_1 line 2 extended permit udp 10.1.1.0 255.255.255.0 any eq snmp
access-list inside_mpc_2 line 1 extended permit icmp any any
: SNMP map for SNMP inspection. Denies all but v3.
: In ASDM, this maps to call-out 4, rule actions, for the class-inside policy.
snmp-map snmp-v3only
deny version 1
deny version 2
deny version 2c
: Inspection policy map to define SIP behavior.
: The sip-high inspection policy map must be referred to by an inspect sip command
: in the service policy map.
: In ASDM, this maps to call-out 4, rule actions, for the sip-class-inside policy.
policy-map type inspect sip sip-high
parameters
rtp-conformance enforce-payloadtype
no traffic-non-sip
software-version action mask log
uri-non-sip action mask log
state-checking action drop-connection log
max-forwards-validation action drop log
strict-header-validation action drop log
: Class map to define traffic matching for the inside-class rule.
: In ASDM, this maps to call-out 3, from the Match to the Time fields.
class-map inside-class
match access-list inside_mpc_1
: Class map to define traffic matching for the sip-class-inside rule.
class-map sip-class-inside
match access-list inside_mpc
: Class map to define traffic matching for the inside-class1 rule.
266
class-map inside-class1
match access-list inside_mpc_2
: Policy map that actually defines the service policy rule set named test-inside-policy.
: In ASDM, this corresponds to the folder at call-out 1.
policy-map test-inside-policy
: First rule in test-inside-policy, named sip-class-inside. Inspects SIP traffic.
: The sip-class-inside rule applies the sip-high inspection policy map to SIP inspection.
: In ASDM, each rule corresponds to call-out 2.
class sip-class-inside
inspect sip sip-high
: Second rule, inside-class. Applies SNMP inspection using an SNMP map.
class inside-class
inspect snmp snmp-v3only
: Third rule, inside-class1. Applies ICMP inspection.
class inside-class1
inspect icmp
: Fourth rule, class-default. Applies connection settings and enables user statistics.
class class-default
set connection timeout embryonic 0:00:30 half-closed 0:10:00 idle 1:00:00
reset dcd 0:15:00 5
user-statistics accounting
: The service-policy command applies the policy map rule set to the inside interface.
: This command activates the policies.
service-policy test-inside-policy interface inside
Features Configured with Service Policies

The following table lists the features you configure using service policies.
Table 10: Features Configured with Service Policies
For Through For Management

Feature Traffic? Traffic? See:
Application inspection (multiple All except RADIUS
types) RADIUS accounting only • Getting Started with Application Layer Protocol
accounting
• Inspection of Basic Internet Protocols, on page 299.
• Inspection for Voice and Video Protocols, on page
331.
• Inspection of Database, Directory, and Management
Protocols.
• ASA and Cisco Cloud Web Security, on page 125.
ASA IPS Yes No See the ASA IPS quick start guide.
ASA CX Yes No See the ASA CX quick start guide.
ASA FirePOWER (ASA SFR) Yes No ASA FirePOWER Module, on page 95.
NetFlow Secure Event Logging Yes Yes See the NetFlow implementation guide.
filtering
QoS input and output policing Yes No Quality of Service, on page 393.
267
For Through For Management

Feature Traffic? Traffic? See:
QoS standard priority queue Yes No Quality of Service, on page 393.
TCP and UDP connection limits Yes Yes Connection Settings, on page 373.
and timeouts, and TCP sequence
number randomization
TCP normalization Yes No Connection Settings, on page 373.
TCP state bypass Yes No Connection Settings, on page 373.
User statistics for Identity Firewall Yes Yes See the user-statistics command in the command
reference.
Feature Directionality
Actions are applied to traffic bidirectionally or unidirectionally depending on the feature. For features that
are applied bidirectionally, all traffic that enters or exits the interface to which you apply the policy map is
affected if the traffic matches the class map for both directions.
Note When you use a global policy, all features are unidirectional; features that are normally bidirectional when
applied to a single interface only apply to the ingress of each interface when applied globally. Because
the policy is applied to all interfaces, the policy will be applied in both directions so bidirectionality in
this case is redundant.
For features that are applied unidirectionally, for example QoS priority queue, only traffic that enters (or exits,
depending on the feature) the interface to which you apply the policy map is affected. See the following table
for the directionality of each feature.
Table 11: Feature Directionality
Feature Single Interface Direction Global Direction

Application inspection (multiple types) Bidirectional Ingress
ASA CX Bidirectional Ingress
ASA CX authentication proxy Ingress Ingress
ASA FirePOWER (ASA SFR) Bidirectional Ingress
ASA IPS Bidirectional Ingress
NetFlow Secure Event Logging filtering N/A Ingress
QoS input policing Ingress Ingress
268
Feature Single Interface Direction Global Direction

QoS output policing Egress Egress
QoS standard priority queue Egress Egress
TCP and UDP connection limits and timeouts, Bidirectional Ingress

and TCP sequence number randomization
TCP normalization Bidirectional Ingress
TCP state bypass Bidirectional Ingress
User statistics for Identity Firewall Bidirectional Ingress
Feature Matching Within a Service Policy

A packet matches rules in a policy for a given interface according to the following rules:
1 A packet can match only one rule for an interface for each feature type.
2 When the packet matches a rule for a feature type, the ASA does not attempt to match it to any subsequent
rules for that feature type.
3 If the packet matches a subsequent rule for a different feature type, however, then the ASA also applies
the actions for the subsequent rule, if supported. See Incompatibility of Certain Feature Actions, on page
270 for more information about unsupported combinations.
Note Application inspection includes multiple inspection types, and most are mutually exclusive. For inspections
that can be combined, each inspection is considered to be a separate feature.
Examples of Packet Matching

For example:
• If a packet matches a rule for connection limits, and also matches a rule for an application inspection,
then both actions are applied.
• If a packet matches a rule for HTTP inspection, but also matches another rule that includes HTTP
inspection, then the second rule actions are not applied.
• If a packet matches a rule for HTTP inspection, but also matches another rule that includes FTP inspection,
then the second rule actions are not applied because HTTP and FTP inspections cannot be combined.
• If a packet matches a rule for HTTP inspection, but also matches another rule that includes IPv6 inspection,
then both actions are applied because the IPv6 inspection can be combined with any other type of
inspection.
269
Order in Which Multiple Feature Actions are Applied

The order in which different types of actions in a service policy are performed is independent of the order in
which the actions appear in the table.
Actions are performed in the following order:
1 QoS input policing
2 TCP normalization, TCP and UDP connection limits and timeouts, TCP sequence number randomization,
and TCP state bypass.
Note When a the ASA performs a proxy service (such as AAA or CSC) or it modifies the TCP payload (such
as FTP inspection), the TCP normalizer acts in dual mode, where it is applied before and after the proxy
or payload modifying service.
3 Application inspections that can be combined with other inspections:

a IPv6
b IP options
c WAAS
4 Application inspections that cannot be combined with other inspections. See Incompatibility of Certain
Feature Actions, on page 270 for more information.
5 ASA IPS
6 ASA CX
7 ASA FirePOWER (ASA SFR)
8 QoS output policing
9 QoS standard priority queue
Note NetFlow Secure Event Logging filtering and User statistics for Identity Firewall are order-independent.
Incompatibility of Certain Feature Actions

Some features are not compatible with each other for the same traffic. The following list might not include
all incompatibilities; for information about compatibility of each feature, see the chapter or section for the
feature:
• You cannot configure QoS priority queuing and QoS policing for the same set of traffic.
• Most inspections should not be combined with another inspection, so the ASA only applies one inspection
if you configure multiple inspections for the same traffic. HTTP inspection can be combined with the
Cloud Web Security inspection. Other exceptions are listed in Order in Which Multiple Feature Actions
are Applied, on page 270.
270
Guidelines for Service Policies
• You cannot configure traffic to be sent to multiple modules, such as the ASA CX and ASA IPS.
• HTTP inspection is not compatible with ASA CX or ASA FirePOWER.
• Cloud Web Security is not compatible with ASA CX or ASA FirePOWER.
Note The Default Inspection Traffic traffic class, which is used in the default global policy, is a special CLI
shortcut to match the default ports for all inspections. When used in a policy map, this class map ensures
that the correct inspection is applied to each packet, based on the destination port of the traffic. For example,
when UDP traffic for port 69 reaches the ASA, then the ASA applies the TFTP inspection; when TCP
traffic for port 21 arrives, then the ASA applies the FTP inspection. So in this case only, you can configure
multiple inspections for the same class map. Normally, the ASA does not use the port number to determine
which inspection to apply, thus giving you the flexibility to apply inspections to non-standard ports, for
example.
This traffic class does not include the default ports for Cloud Web Security inspection (80 and 443).
Feature Matching for Multiple Service Policies

For TCP and UDP traffic (and ICMP when you enable stateful ICMP inspection), service policies operate on
traffic flows, and not just individual packets. If traffic is part of an existing connection that matches a feature
in a policy on one interface, that traffic flow cannot also match the same feature in a policy on another interface;
only the first policy is used.
For example, if HTTP traffic matches a policy on the inside interface to inspect HTTP traffic, and you have
a separate policy on the outside interface for HTTP inspection, then that traffic is not also inspected on the
egress of the outside interface. Similarly, the return traffic for that connection will not be inspected by the
ingress policy of the outside interface, nor by the egress policy of the inside interface.
For traffic that is not treated as a flow, for example ICMP when you do not enable stateful ICMP inspection,
returning traffic can match a different policy map on the returning interface. For example, if you configure
IPS on the inside and outside interfaces, but the inside policy uses virtual sensor 1 while the outside policy
uses virtual sensor 2, then a non-stateful Ping will match virtual sensor 1 outbound, but will match virtual
sensor 2 inbound.
Guidelines for Service Policies

IPv6 Guidelines
Supports IPv6 for the following features:
• Application inspection for DNS, FTP, HTTP, ICMP, ScanSafe, SIP, SMTP, IPsec-pass-thru, and IPv6.
• ASA IPS
• ASA CX
• ASA FirePOWER
• NetFlow Secure Event Logging filtering
• TCP and UDP connection limits and timeouts, TCP sequence number randomization
271
Defaults for Service Policies
• TCP normalization
• TCP state bypass
• User statistics for Identity Firewall
Class Map (Traffic Class) Guidelines

The maximum number of class maps (traffic classes) of all types is 255 in single mode or per context in
multiple mode. Class maps include the following types:
• Layer 3/4 class maps (for through traffic and management traffic).
• Inspection class maps
• Regular expression class maps
• match commands used directly underneath an inspection policy map
This limit also includes default class maps of all types, limiting user-configured class maps to approximately
235.
Service Policy Guidelines

• Interface service policies on ingress interfaces take precedence over the global service policy for a given
feature. For example, if you have a global policy with FTP inspection, and an interface policy with TCP
normalization, then both FTP inspection and TCP normalization are applied to the interface. However,
if you have a global policy with FTP inspection, and an ingress interface policy with FTP inspection,
then only the ingress interface policy FTP inspection is applied to that interface. If no ingress or global
policy implements a feature, then an interface service policy on the egress interface that specifies the
feature is applied.
• You can only apply one global policy. For example, you cannot create a global policy that includes
feature set 1, and a separate global policy that includes feature set 2. All features must be included in a
single policy.
• 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. Output for the show command will not include data about the old connections.
For example, if you remove a QoS service policy from an interface, then add a modified version, then
the show service-policy command only displays QoS counters associated with new connections that
match the new service policy; existing connections on the old policy no longer show in the command
output.
To ensure that all connections use the new policy, you need to disconnect the current connections so
they can reconnect using the new policy. Use the clear conn or clear local-host commands.

The following topics describe the default settings for service policies and the Modular Policy Framework.
272
Default Service Policy Configuration

By default, the configuration includes a policy that matches all default application inspection traffic and applies
certain inspections to the traffic on all interfaces (a global policy). Not all inspections are enabled by default.
You can only apply one global policy, so if you want to alter the global policy, you need to either edit the
default policy or disable it and apply a new one. (An interface policy overrides the global policy for a particular
feature.)
The default policy includes the following application inspections:
• DNS
• FTP
• H323 (H225)
• H323 (RAS)
• RSH
• RTSP
• ESMTP
• SQLnet
• Skinny (SCCP)
• SunRPC
• XDMCP
• SIP
• NetBios
• TFTP
• IP Options
Default Class Maps (Traffic Classes)

The configuration includes a default Layer 3/4 class map (traffic class) that the ASA uses in the default global
policy called Default Inspection Traffic; it matches the default inspection traffic. This class, which is used in
the default global policy, is a special shortcut to match the default ports for all inspections.
When used in a policy, this class ensures that the correct inspection is applied to each packet, based on the
destination port of the traffic. For example, when UDP traffic for port 69 reaches the ASA, then the ASA
applies the TFTP inspection; when TCP traffic for port 21 arrives, then the ASA applies the FTP inspection.
So in this case only, you can configure multiple inspections for the same class map. Normally, the ASA does
not use the port number to determine which inspection to apply, thus giving you the flexibility to apply
inspections to non-standard ports, for example.
Another class map that exists in the default configuration is called class-default, and it matches all traffic.
You can use the class-default class if desired, rather than using the Any traffic class. In fact, some features
are only available for class-default.
273
Configure Service Policies

Configuring a service policy consists of adding one or more service policy rules per interface or for the global
policy. ASDM uses a wizard to take you through the process of creating a service policy. For each rule, you
identify the following elements:
1 The interface to which you want to apply the rule, or the global policy.
2 The traffic to which you want to apply actions. You can identify Layer 3 and 4 traffic.
3 The actions to apply to the traffic class. You can apply multiple non-conflicting actions for each traffic
class.
After you create a policy, you can add rules, move, edit, or delete rules or policies. The following topics
explain how to configure service policies.
Add a Service Policy Rule for Through Traffic

To add a service policy rule for through traffic, use the Add Service Policy Rule wizard. You will be asked
to choose the scope of the policy, for a specific interface or global:
• Interface service policies take precedence over the global service policy for a given feature. For example,
if you have a global policy with FTP inspection, and an interface policy with TCP connection limits,
then both FTP inspection and TCP connection limits are applied to the interface. However, if you have
a global policy with FTP inspection, and an interface policy with FTP inspection, then only the interface
policy FTP inspection is applied to that interface.
• Global service policies provide default services to all interfaces. Unless overridden by an interface-specific
policy, the global services are applied. By default, a global policy exists that includes a service policy
rule for default application inspection. You can add a rule to the global policy using the wizard.
Procedure
Step 1 Choose Configuration > Firewall > Service Policy Rules, and click Add or Add > Add Service Policy
Rule.
274
Step 2 In the Create a Service Policy and Apply To area:

a) Choose whether the policy applies to a specific Interface or Global to all interfaces.
b) If you select Interface, choose the name of the interface. If the interface already has a policy, then you are
adding a rule to the existing policy.
c) If the interface does not already have a service policy, enter the name of the new policy.
d) (Optional) Enter a description for the policy.
e) (Optional) Check the Drop and log unsupported IPv6 to IPv6 traffic option to generate a syslog (767001)
for IPv6 traffic that is dropped by application inspections that do not support IPv6 traffic. By default,
syslogs are not generated.
f) Click Next.
to apply the policy actions and click Next.
• Create a new traffic class. Enter a traffic class name and an optional description.
Identify the traffic using one of several criteria:
◦Default Inspection Traffic—The class matches the default TCP and UDP ports used by all
applications that the ASA can inspect. When you click Next, you are shown the services and ports
defined by this class.
This option, which is used in the default global policy, is a special shortcut that when used in a
rule, ensures that the correct inspection is applied to each packet, based on the destination port of
the traffic. For more information, see Default Class Maps (Traffic Classes), on page 273.
275
See Default Inspections and NAT Limitations, on page 284 for a list of default ports. The ASA
includes a default global policy that matches the default inspection traffic, and applies common
inspections to the traffic on all interfaces. Not all applications whose ports are included in the
Default Inspection Traffic class are enabled by default in the policy map.
You can specify a Source and Destination IP Address class (which uses an ACL) along with the
Default Inspection Traffic class to narrow the matched traffic. Because the Default Inspection
Traffic class specifies the ports and protocols to match, any ports and protocols in the ACL are
ignored.
◦Source and Destination IP Address (uses ACL)—The class matches traffic specified by an
extended ACL. If the ASA is operating in transparent firewall mode, you can use an EtherType
ACL. When you click Next, you are prompted for the attributes of the access control entry. The
wizard builds the ACL, you cannot select an existing ACL.
When defining the ACE, the Match option creates a rule where traffic matching the addresses have
actions applied. The Do Not Match option exempts the traffic from having the specified actions
applied. For example, you want to match all traffic in 10.1.1.0/24 and apply connection limits to
it, except for 10.1.1.25. In this case, create two rules, one for 10.1.1.0/24 using the Match option
and one for 10.1.1.25 using the Do Not Match option. Be sure to arrange the rules so that the Do
Not Match rule is above the Match rule, or else 10.1.1.25 will match the Match rule first.
Note When you create a new traffic class of this type, you can only specify one access control
entry (ACE) initially. After you finish adding the rule, you can add additional ACEs by
adding a new rule to the same interface or global policy, and then specifying Add rule
to existing traffic class (see below).
◦Tunnel Group—The class matches traffic for a tunnel group (connection profile) to which you
want to apply QoS. You can also specify one other traffic match option to refine the traffic match,
excluding Any Traffic, Source and Destination IP Address (uses ACL), or Default Inspection
Traffic.
When you click Next, you are prompted to select the tunnel group (you can create a new one if
necessary). To police each flow, check Match flow destination IP address. All traffic going to
a unique IP destination address is considered a flow.
◦TCP or UDP Destination Port—The class matches a single port or a contiguous range of ports.
When you click Next, you are prompted to choose either TCP or UDP and enter the port number;
click ... to choose one already defined in ASDM.
Tip For applications that use multiple, non-contiguous ports, use the Source and Destination IP
Address (uses ACL) to match each port.
◦RTP Range—The class map matches RTP traffic. When you click Next, you are prompted to
enter an RTP port range, between 2000 and 65534. The maximum number of ports in the range is
16383.
◦IP DiffServ CodePoints (DSCP)—The class matches up to eight DSCP values in the IP header.
When you click Next, you are prompted to select or enter the desired values (move them into the
Match on DSCP list).
◦IP Precedence—The class map matches up to four precedence values, represented by the TOS
byte in the IP header. When you click Next, you are prompted for the values.
◦Any Traffic—Matches all traffic.
276
• Add rule to existing traffic class. If you already have a service policy rule on the same interface, or
you are adding to the global service policy, this option lets you add an ACE to an existing ACL. You
can add an ACE to any ACL that you previously created when you chose the Source and Destination
IP Address (uses ACL) option for a service policy rule on this interface. For this traffic class, you can
have only one set of rule actions even if you add multiple ACEs. You can add multiple ACEs to the
same traffic class by repeating this entire procedure. When you click Next, you are prompted for the
attributes of the access control entry.
• Use an existing traffic class. If you created a traffic class used by a rule on a different interface, you
can reuse the traffic class definition for this rule. Note that if you alter the traffic class for one rule, the
change is inherited by all rules that use that traffic class. If your configuration includes any class-map
commands that you entered at the CLI, those traffic class names are also available (although to view the
definition of the traffic class, you need to create the rule).
• Use class default as the traffic class. This option uses the class-default class, which matches all traffic.
The class-default class is created automatically by the ASA and placed at the end of the policy. If you
do not apply any actions to it, it is still created by the ASA, but for internal purposes only. You can apply
actions to this class, if desired, which might be more convenient than creating a new traffic class that
matches all traffic. You can only create one rule for this service policy using the class-default class,
because each traffic class can only be associated with a single rule per service policy.
Step 4 If you selected a traffic matching criteria that requires additional configuration, enter the desired parameters
and click Next.
Step 5 On the Rule Actions page, configure one or more rule actions. See Features Configured with Service Policies,
on page 267 for a list of features and actions that you can apply, with pointers to additional details.
Add a Service Policy Rule for Management Traffic

To add a service policy rule for traffic directed to the ASA for management purposes, use the Add Service
Policy Rule wizard. You will be asked to choose the scope of the policy, for a specific interface or global:
• Interface service policies take precedence over the global service policy for a given feature. For example,
if you have a global policy with RADIUS accounting inspection, and an interface policy with connection
limits, then both RADIUS accounting and connection limits are applied to the interface. However, if
you have a global policy with RADIUS accounting, and an interface policy with RADIUS accounting,
then only the interface policy RADIUS accounting is applied to that interface.
• Global service policies provide default services to all interfaces. Unless overridden by an interface-specific
policy, the global services are applied. By default, a global policy exists that includes a service policy
rule for default application inspection. You can add a rule to the global policy using the wizard.
Procedure
Step 1 Choose Configuration > Firewall > Service Policy Rules, and click Add or Add > Add Management
Service Policy Rule.
Step 2 In the Create a Service Policy and Apply To area:
277
a) Choose whether the policy applies to a specific Interface or Global to all interfaces.
b) If you select Interface, choose the name of the interface. If the interface already has a policy, then you are
adding a rule to the existing policy.
c) If the interface does not already have a service policy, enter the name of the new policy.
d) (Optional) Enter a description for the policy.
e) Click Next.
to apply the policy actions and click Next.
• Create a new traffic class. Enter a traffic class name and an optional description.
Identify the traffic using one of several criteria:
◦Source and Destination IP Address (uses ACL)—The class matches traffic specified by an
extended ACL. If the ASA is operating in transparent firewall mode, you can use an EtherType
ACL. When you click Next, you are prompted for the attributes of the access control entry. The
wizard builds the ACL, you cannot select an existing ACL.
When defining the ACE, the Match option creates a rule where traffic matching the addresses have
actions applied. The Do Not Match option exempts the traffic from having the specified actions
applied. For example, you want to match all traffic in 10.1.1.0/24 and apply connection limits to
it, except for 10.1.1.25. In this case, create two rules, one for 10.1.1.0/24 using the Match option
and one for 10.1.1.25 using the Do Not Match option. Be sure to arrange the rules so that the Do
Not Match rule is above the Match rule, or else 10.1.1.25 will match the Match rule first.
◦TCP or UDP Destination Port—The class matches a single port or a contiguous range of ports.
When you click Next, you are prompted to choose either TCP or UDP and enter the port number;
click ... to choose one already defined in ASDM.
Tip For applications that use multiple, non-contiguous ports, use the Source and Destination IP
Address (uses ACL) to match each port.
• Add rule to existing traffic class. If you already have a service policy rule on the same interface, or
you are adding to the global service policy, this option lets you add an ACE to an existing ACL. You
can add an ACE to any ACL that you previously created when you chose the Source and Destination
IP Address (uses ACL) option for a service policy rule on this interface. For this traffic class, you can
have only one set of rule actions even if you add multiple ACEs. You can add multiple ACEs to the
same traffic class by repeating this entire procedure. When you click Next, you are prompted for the
attributes of the access control entry.
• Use an existing traffic class. If you created a traffic class used by a rule on a different interface, you
can reuse the traffic class definition for this rule. Note that if you alter the traffic class for one rule, the
change is inherited by all rules that use that traffic class. If your configuration includes any class-map
commands that you entered at the CLI, those traffic class names are also available (although to view the
definition of the traffic class, you need to create the rule).
Step 4 If you selected a traffic matching criteria that requires additional configuration, enter the desired parameters
and click Next.
Step 5 On the Rule Actions page, configure one or more rule actions.
• To configure RADIUS accounting inspection, choose an inspect map from the RADIUS Accounting
Map drop-down list, or click Configure to add a map. See Features Configured with Service Policies,
on page 267 for more information.
278
• To configure connection settings, see Configure Connection Settings for Specific Traffic Classes (All
Services), on page 387.
Manage the Order of Service Policy Rules

The order of service policy rules on an interface or in the global policy affects how actions are applied to
traffic. See the following guidelines for how a packet matches rules in a service policy:
• A packet can match only one rule in a service policy for each feature type.
• When the packet matches a rule that includes actions for a feature type, the ASA does not attempt to
match it to any subsequent rules including that feature type.
• If the packet matches a subsequent rule for a different feature type, however, then the ASA also applies
the actions for the subsequent rule.
For example, if a packet matches a rule for connection limits, and also matches a rule for application inspection,
then both rule actions are applied.
If a packet matches a rule for application inspection, but also matches another rule that includes application
inspection, then the second rule actions are not applied.
If your rule includes an ACL with multiple ACEs, then the order of ACEs also affects the packet flow. The
ASA tests the packet 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 create an ACE at the beginning of an ACL that explicitly permits
all traffic, no further statements are ever checked.
To change the order of rules or ACEs within a rule, perform the following steps:
Procedure
Step 1 On the Configuration > Firewall > Service Policy Rules pane, choose the rule or ACE that you want to
move up or down.
Step 2 Click the Move Up or Move Down button.
279
History for Service Policies
Note If you rearrange ACEs in an ACL that is used in multiple service policies, then the change is inherited
in all service policies.
Step 3 When you are done rearranging your rules or ACEs, click Apply.
History for Service Policies

Modular Policy Framework 7.0(1) Modular Policy Framework was introduced.
Management class map for use with RADIUS 7.2(1) The management class map was introduced for use with
accounting traffic RADIUS accounting traffic. The following commands were
introduced: class-map type management, and inspect
radius-accounting.
Inspection policy maps 7.2(1) The inspection policy map was introduced. The following
command was introduced: class-map type inspect.
Regular expressions and policy maps 7.2(1) Regular expressions and policy maps were introduced to be
used under inspection policy maps. The following commands
were introduced: class-map type regex, regex, match regex.
Match any for inspection policy maps 8.0(2) The match any keyword was introduced for use with inspection
policy maps: traffic can match one or more criteria to match
the class map. Formerly, only match all was available.
280
CHAPTER 12
Getting Started with Application Layer Protocol
Inspection
The following topics describe how to configure application layer protocol inspection.
• Application Layer Protocol Inspection, page 281

• Guidelines for Application Inspection, page 283
• Defaults for Application Inspection, page 284
• Configure Application Layer Protocol Inspection, page 288
• Configure Regular Expressions, page 292
• Monitoring Inspection Policies, page 296
• History for Application Inspection, page 297
Application Layer Protocol Inspection

Inspection engines are required for services that embed IP addressing information in the user data packet or
that open secondary channels on dynamically assigned ports. These protocols require the ASA to do a deep
packet inspection instead of passing the packet through the fast path. As a result, inspection engines can affect
overall throughput. Several common inspection engines are enabled on the ASA by default, but you might
need to enable others depending on your network.
The following topics explain application inspection in more detail.
When to Use Application Protocol Inspection

When a user establishes a connection, the ASA checks the packet against ACLs, creates an address translation,
and creates an entry for the session in the fast path, so that further packets can bypass time-consuming checks.
However, the fast path relies on predictable port numbers and does not perform address translations inside a
packet.
Many protocols open secondary TCP or UDP ports. The initial session on a well-known port is used to negotiate
dynamically assigned port numbers.
281
Application Layer Protocol Inspection
Other applications embed an IP address in the packet that needs to match the source address that is normally
translated when it goes through the ASA.
If you use applications like these, then you need to enable application inspection.
When you enable application inspection for a service that embeds IP addresses, the ASA translates embedded
addresses and updates any checksum or other fields that are affected by the translation.
When you enable application inspection for a service that uses dynamically assigned ports, the ASA monitors
sessions to identify the dynamic port assignments, and permits data exchange on these ports for the duration
of the specific session.
Inspection Policy Maps

You can configure special actions for many application inspections using an inspection policy map. These
maps are optional: you can enable inspection for a protocol that supports inspection policy maps without
configuring a map. These maps are needed only if you want something other than the default inspection
actions.
An inspection policy map consists of one or more of the following elements. The exact options available for
an inspection policy map depends on the application.
• Traffic matching criteria—You match application traffic to criteria specific to the application, such as
a URL string, for which you then enable actions.
For some traffic matching criteria, you use regular expressions to match text inside a packet. Be sure to
create and test the regular expressions before you configure the policy map, either singly or grouped
together in a regular expression class map.
• Inspection class map—Some inspection policy maps let you use an inspection class map to include
multiple traffic matching criteria. You then identify the inspection class map in the inspection policy
map and enable actions for the class as a whole. The difference between creating a class map and defining
the traffic match directly in the inspection policy map is that you can create more complex match criteria
and you can reuse class maps. However, you cannot set different actions for different matches.
• Parameters—Parameters affect the behavior of the inspection engine.
The following topics provide more details.
Replacing an In-Use Inspection Policy Map

If you have an inspection enabled with a policy map in a service policy, replacing the policy map is a two-step
process. First, you must remove the inspection from the service policy and apply changes. Then, you add it
back, select the new policy map name, and again apply changes.
How Multiple Traffic Classes are Handled

You can specify multiple inspection class maps or direct matches in the inspection policy map.
If a packet matches multiple different classes or direct matches, then the order in which the ASA applies the
actions is determined by internal ASA rules, and not by the order they are added to the inspection policy map.
The internal rules are determined by the application type and the logical progression of parsing a packet, and
are not user-configurable. For example for HTTP traffic, parsing a Request Method field precedes parsing
the Header Host Length field; an action for the Request Method field occurs before the action for the Header
Host Length field.
282
Guidelines for Application Inspection
If an action drops a packet, then no further actions are performed in the inspection policy map. For example,
if the first action is to reset the connection, then it will never match any further match criteria. If the first action
is to log the packet, then a second action, such as resetting the connection, can occur.
If a packet matches multiple match criteria that are the same, then they are matched in the order they appear
in the policy map.
A class map is determined to be the same type as another class map or direct match based on the lowest priority
match option in the class map (the priority is based on the internal rules). If a class map has the same type of
lowest priority match option as another class map, then the class maps are matched according to the order
they are added to the policy map. If the lowest priority match for each class map is different, then the class
map with the higher priority match option is matched first.
Guidelines for Application Inspection

Failover
State information for multimedia sessions that require inspection are not passed over the state link for stateful
failover. The exceptions are GTP and SIP, which are replicated over the state link.
Clustering
The following inspections are not supported in clustering:
• CTIQBE
• Diameter inspection of SCTP traffic. Inspection of TCP traffic is supported.
• H323, H225, and RAS
• IPsec passthrough
• MGCP
• MMP
• RTSP
• SCCP (Skinny)
• WAAS
IPv6
Supports IPv6 for the following inspections:
• Diameter
• DNS
• FTP
• GTP
• HTTP
• ICMP
• IPsec pass-through
283
Defaults for Application Inspection
• IPv6
• SCCP (Skinny)
• SCTP
• SIP
• SMTP
• VXLAN
Supports NAT64 for the following inspections:

• DNS
• FTP
• HTTP
• ICMP
• SCTP
• Some inspection engines do not support PAT, NAT, outside NAT, or NAT between same security
interfaces. For more information about NAT support, see Default Inspections and NAT Limitations,
on page 284.
• For all the application inspections, the ASA limits the number of simultaneous, active data connections
to 200 connections. For example, if an FTP client opens multiple secondary connections, the FTP
inspection engine allows only 200 active connections and the 201 connection is dropped and the adaptive
security appliance generates a system error message.
• Inspected protocols are subject to advanced TCP-state tracking, and the TCP state of these connections
is not automatically replicated. While these connections are replicated to the standby unit, there is a
best-effort attempt to re-establish a TCP state.
• TCP/UDP Traffic directed to the ASA (to an interface) is inspected by default. However, ICMP traffic
directed to an interface is never inspected, even if you enable ICMP inspection. Thus, a ping (echo
request) to an interface can fail under specific circumstances, such as when the echo request comes from
a source that the ASA can reach through a backup default route.

The following topics explain the default operations for application inspection.
Default Inspections and NAT Limitations

By default, the configuration includes a policy that matches all default application inspection traffic and applies
inspection to the traffic on all interfaces (a global policy). Default application inspection traffic includes traffic
to the default ports for each protocol. You can only apply one global policy, so if you want to alter the global
policy, for example, to apply inspection to non-standard ports, or to add inspections that are not enabled by
default, you need to either edit the default policy or disable it and apply a new one.
284
The following table lists all inspections supported, the default ports used in the default class map, and the
inspection engines that are on by default, shown in bold. This table also notes any NAT limitations. In this
table:
• Inspection engines that are enabled by default for the default port are in bold.
• The ASA is in compliance with the indicated standards, but it does not enforce compliance on packets
being inspected. For example, FTP commands are supposed to be in a particular order, but the ASA
does not enforce the order.
Table 12: Supported Application Inspection Engines
Default Protocol,
Application Port NAT Limitations Standards Comments
CTIQBE TCP/2748 No extended PAT. — —
No NAT64.
(Clustering) No static PAT.
DCERPC TCP/135 No NAT64. — —
Diameter TCP/3868 No NAT/PAT. RFC 6733 Requires the Carrier license.

SCTP/3868
DNS over UDP UDP/53 No NAT support is available for RFC 1123 —
name resolution through WINS.
FTP TCP/21 (Clustering) No static PAT. RFC 959 —
GTP UDP/3386 No extended PAT. — Requires the Carrier license.

(GTPv0) No NAT.
UDP/2123
(GTPv1+)
H.323 H.225 and TCP/1720 No dynamic NAT. ITU-T H.323, —

RAS UDP/1718 UDP Static PAT may not work. H.245, H225.0,
(RAS) Q.931, Q.932
1718-1719 (Clustering) No static PAT.
No extended PAT.
No per-session PAT.
No NAT on same security interfaces.
No NAT64.
HTTP TCP/80 — RFC 2616 Beware of MTU limitations stripping

ActiveX and Java. If the MTU is too
small to allow the Java or ActiveX
tag to be included in one packet,
stripping may not occur.
285
Default Protocol,
ICMP ICMP — — ICMP traffic directed to an ASA
interface is never inspected.
ICMP ERROR ICMP — — —
ILS (LDAP) TCP/389 No extended PAT. — —

No NAT64.
Instant Varies by client No extended PAT. RFC 3860 —

Messaging (IM) No NAT64.
IP Options RSVP No NAT64. RFC 791, RFC —

2113
IPsec Pass UDP/500 No PAT. — —

Through No NAT64.
IPv6 — No NAT64. RFC 2460 —
LISP — No NAT or PAT. — —
MGCP UDP/2427, 2727 No extended PAT. RFC 2705bis-05 —

No NAT64.
MMP TCP/5443 No extended PAT. — —

No NAT64.
NetBIOS Name UDP/137, 138 No extended PAT. — NetBIOS is supported by performing

Server over IP (Source ports) NAT of the packets for NBNS UDP
No NAT64.
port 137 and NBDS UDP port 138.
PPTP TCP/1723 No NAT64. RFC 2637 —

RADIUS UDP/1646 No NAT64. RFC 2865 —

Accounting
RSH TCP/514 No PAT. Berkeley UNIX —

No NAT64.
286
Default Protocol,
RTSP TCP/554 No extended PAT. RFC 2326, 2327, No handling for HTTP cloaking.
1889
No NAT64.
ScanSafe (Cloud TCP/80 TCP/413 — — These ports are not included in the
Web Security) default-inspection-traffic class for
the ScanSafe inspection.
SCTP SCTP — RFC 4960 Requires the Carrier license.

Although you can do static network
object NAT on SCTP traffic (no
dyamic NAT/PAT), the inspection
engine is not used for NAT.
SIP TCP/5060 No NAT on same security interfaces. RFC 2543 Does not handle TFTP uploaded
UDP/5060 Cisco IP Phone configurations under
No extended PAT.
certain circumstances.
No per-session PAT.
No NAT64 or NAT46.
SKINNY TCP/2000 No NAT on same security interfaces. — Does not handle TFTP uploaded
(SCCP) Cisco IP Phone configurations under
No extended PAT.
certain circumstances.
No per-session PAT.
No NAT64, NAT46, or NAT66.
SMTP and TCP/25 No NAT64. RFC 821, 1123 —

ESMTP
SNMP UDP/161, 162 No NAT or PAT. RFC 1155, 1157, v.2 RFC 1902-1908; v.3 RFC
1212, 1213, 1215 2570-2580.
SQL*Net TCP/1521 No extended PAT. — v.1 and v.2.

No NAT64.
Sun RPC over UDP/111 No extended PAT. — The default rule includes UDP port
UDP and TCP 111; if you want to enable Sun RPC
No NAT64.
inspection for TCP port 111, you
need to create a new rule that
matches TCP port 111 and performs
Sun RPC inspection.
287
Configure Application Layer Protocol Inspection
Default Protocol,
TFTP UDP/69 No NAT64. RFC 1350 Payload IP addresses are not
translated.
WAAS TCP/1- 65535 No extended PAT. — —

No NAT64.
XDMCP UDP/177 No extended PAT. — —

No NAT64.
VXLAN UDP/4789 Not applicable RFC 7348 Virtual Extensible Local Area
Network.
Default Inspection Policy Maps

Some inspection types use hidden default policy maps. For example, if you enable ESMTP inspection without
specifying a map, _default_esmtp_map is used.
The default inspection is described in the sections that explain each inspection type. You can view these
default maps using the show running-config all policy-map command; use Tools > Command Line Interface.
DNS inspection is the only one that uses an explicitly-configured default map, preset_dns_map.

You configure application inspection in service policies.
Inspection is enabled by default globally on all interfaces for some applications on their standard ports and
protocols. See Default Inspections and NAT Limitations, on page 284 for more information on default
inspections. A common method for customizing the inspection configuration is to customize the default global
policy. You can alternatively create a new service policy as desired, for example, an interface-specific policy.
Before You Begin

For some applications, you can perform special actions when you enable inspection by configuring inspection
policy maps. The table later in this procedure shows which protocols allow inspection policy maps, with
pointers to the instructions on configuring them. If you want to configure these advanced features, create the
map before configuring inspection.
Procedure
Step 1 Choose Configuration > Firewall > Service Policy Rules.

Step 2 Open a rule.
• To edit the default global policy, select the “inspection_default” rule in the Global folder and click Edit.
288
• To create a new rule, click Add > Add Service Policy Rule. Proceed through the wizard to the Rules
page.
• If you have another inspection rule, or a rule to which you are adding an inspection, select it and click
Edit.
If you want to match non-standard ports, then create a new rule for the non-standard ports. See Default
Inspections and NAT Limitations, on page 284 for the standard ports for each inspection engine.
You can combine multiple rules in the same service policy if desired, so you can create one rule to match
certain traffic, and another to match different traffic. However, if traffic matches a rule that contains an
inspection action, and then matches another rule that also has an inspection action, only the first matching
rule is used.
If you are implementing RADIUS accounting inspection, create a management service policy rule instead.
See Configure RADIUS Accounting Inspection, on page 365.
Step 3 On the Rule Actions wizard page or tab, select the Protocol Inspection tab.
Step 4 (To change an in-use policy) If you are editing any in-use policy to use a different inspection policy map, you
must disable the inspection, and then re-enable it with the new inspection policy map name:
a) Uncheck the protocol’s check box.
b) Click OK.
c) Click Apply.
d) Repeat these steps to return to the Protocol Inspections tab.
Step 5 Select the inspection type that you want to apply.
You can select multiple options on the default inspection traffic class only.
Some inspection engines let you control additional parameters when you apply the inspection to the traffic.
Click Configure for the inspection type to configure an inspection policy map and other options. You can
either choose an existing map, or create a new one. You can predefine inspection policy maps from the
Configuration > Firewall > Objects > Inspect Maps list.
The following table lists the protocols you can inspect, whether they allow inspection policy maps or inspection
class maps, and a pointer to detailed information about the inspection.
Table 13: Inspection Protocols
Supports Supports
Inspection Inspection Class
Protocol Policy Maps Maps Notes
CTIQBE No No See CTIQBE Inspection, on page 331.
Cloud Web Yes Yes If you want to enable ScanSafe (Cloud Web Security),
Security use the procedure described in the following topic
rather than this procedure: Configure a Service Policy
to Send Traffic to Cloud Web Security, on page 133.
The cited procedure explains the full policy
configuration, including how to configure the policy
inspection map.
DCERPC Yes Yes See DCERPC Inspection, on page 300.
289
Supports Supports
Diameter Yes Yes See Diameter Inspection, on page 354.
DNS Yes Yes See DNS Inspection, on page 302.

If you are using the Botnet Traffic Filter, choose
Enable DNS snooping. We suggest that you enable
DNS snooping only on interfaces where external DNS
requests are going. Enabling DNS snooping on all
UDP DNS traffic, including that going to an internal
DNS server, creates unnecessary load on the ASA.
For example, if the DNS server is on the outside
interface, you should enable DNS inspection with
snooping for all UDP DNS traffic on the outside
interface.
ESMTP Yes No See SMTP and Extended SMTP Inspection, on page

322.
FTP Yes Yes See FTP Inspection, on page 305.

Select Use Strict FTP to select an inspection policy
map. Strict FTP increases the security of protected
networks by preventing web browsers from sending
embedded commands in FTP requests.
GTP Yes No See GTP Inspection.
H.323 H.225 Yes Yes See H.323 Inspection, on page 332.
H.323 RAS Yes Yes See H.323 Inspection, on page 332.
HTTP Yes Yes See HTTP Inspection, on page 309.
ICMP No No See ICMP Inspection, on page 313.
ICMP Error No No See ICMP Error Inspection, on page 313.
ILS No No See ILS Inspection, on page 314.
IM Yes Yes See Instant Messaging Inspection, on page 314.
IP-Options Yes No See IP Options Inspection, on page 316.
IPSec Pass Thru Yes No See IPsec Pass Through Inspection, on page 318.
IPv6 Yes No See IPv6 Inspection, on page 319.
290
Supports Supports
LISP Yes No For detailed information on configuring LISP,
including inspection, see the clustering chapter in the
general configuration guide.
MGCP Yes No See MGCP Inspection, on page 336.
NetBIOS Yes No See NetBIOS Inspection, on page 320.
PPTP No No See PPTP Inspection, on page 321.
RADIUS Yes No See RADIUS Accounting Inspection.

Accounting
RADIUS accounting inspection is available for a
management service policy only. You must select a
policy map to implement this inspection.
RSH No No See RSH Inspection, on page 321.
RTSP Yes No See RTSP Inspection, on page 338.
SCCP (Skinny) Yes No See Skinny (SCCP) Inspection, on page 345.

If you want to inspect encrypted SCCP traffic, choose
Enable encrypted traffic inspection and select a
TLS proxy (click Manage to create one if necessary).
SCTP Yes No See SCTP Application Layer Inspection, on page

354.
SIP Yes Yes See SIP Inspection, on page 341.

If you want to inspect encrypted SIP traffic, choose
Enable encrypted traffic inspection and select a
TLS proxy (click Manage to create one if necessary).
SNMP Yes No See SNMP Inspection, on page 325.
SQLNET No No See SQL*Net Inspection, on page 326.
SUNRPC No No See Sun RPC Inspection, on page 326.

The default class map includes UDP port 111; if you
want to enable Sun RPC inspection for TCP port 111,
you need to create a new class map that matches TCP
port 111, add the class to the policy, and then apply
SUNRPC inspection to that class.
TFTP No No See TFTP Inspection, on page 328.
291
Configure Regular Expressions
Supports Supports
WAAS No No Enables TCP option 33 parsing. Use when deploying
Cisco Wide Area Application Services products.
XDMCP No No See XDMCP Inspection, on page 328.
VXLAN No No See VXLAN Inspection, on page 329.
Step 6 Click OK or Finish to save the service policy rule.

Regular expressions define pattern matching for text strings. You can use these expressions in some protocol
inspection maps to match packets based on strings such as URLs or the contents of particular header fields.
Create a Regular Expression

A regular expression matches text strings either literally as an exact string, or by using metacharacters so that
you can match multiple variants of a text string. You can use a regular expression to match the content of
certain application traffic; for example, you can match a URL string inside an HTTP packet.
Before You Begin

See the regex command in the command reference for performance impact information when matching a
regular expression to packets. In general, matching against long input strings, or trying to match a large number
of regular expressions, will reduce system performance.
Note As an optimization, the ASA searches on the deobfuscated URL. Deobfuscation compresses multiple
forward slashes (/) into a single slash. For strings that commonly use double slashes, like “http://”, be sure
to search for “http:/” instead.
The following table lists the metacharacters that have special meanings.
Table 14: Regular Expression Metacharacters
Character Description Notes

. Dot Matches any single character. For example, d.g
matches dog, dag, dtg, and any word that contains
those characters, such as doggonnit.
292

(exp) Subexpression A subexpression segregates characters from
surrounding characters, so that you can use other
metacharacters on the subexpression. For example,
d(o|a)g matches dog and dag, but do|ag matches do
and ag. A subexpression can also be used with repeat
quantifiers to differentiate the characters meant for
repetition. For example, ab(xy){3}z matches
abxyxyxyz.
| Alternation Matches either expression it separates. For example,

dog|cat matches dog or cat.
? Question mark A quantifier that indicates that there are 0 or 1 of the

previous expression. For example, lo?se matches lse
or lose.
* Asterisk A quantifier that indicates that there are 0, 1 or any

number of the previous expression. For example,
lo*se matches lse, lose, loose, and so on.
+ Plus A quantifier that indicates that there is at least 1 of

the previous expression. For example, lo+se matches
lose and loose, but not lse.
{x} or {x,} Minimum repeat quantifier Repeat at least x times. For example, ab(xy){2,}z
matches abxyxyz, abxyxyxyz, and so on.
[abc] Character class Matches any character in the brackets. For example,
[abc] matches a, b, or c.
[âbc] Negated character class Matches a single character that is not contained within
the brackets. For example, [âbc] matches any
character other than a, b, or c. [Â-Z] matches any
single character that is not an uppercase letter.
[a-c] Character range class Matches any character in the range. [a-z] matches
any lowercase letter. You can mix characters and
ranges: [abcq-z] matches a, b, c, q, r, s, t, u, v, w, x,
y, z, and so does [a-cq-z].
The dash (-) character is literal only if it is the last or
the first character within the brackets: [abc-] or
[-abc].
“” Quotation marks Preserves trailing or leading spaces in the string. For

example, “ test” preserves the leading space when it
looks for a match.
^ Caret Specifies the beginning of a line.
293

\ Escape character When used with a metacharacter, matches a literal
character. For example, \[ matches the left square
bracket.
char Character When character is not a metacharacter, matches the

literal character.
\r Carriage return Matches a carriage return 0x0d.
\n Newline Matches a new line 0x0a.
\t Tab Matches a tab 0x09.
\f Formfeed Matches a form feed 0x0c.
\xNN Escaped hexadecimal number Matches an ASCII character using hexadecimal

(exactly two digits).
\NNN Escaped octal number Matches an ASCII character as octal (exactly three
digits). For example, the character 040 represents a
space.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Regular Expressions.
Step 2 In the Regular Expressions area, do one of the following:
Step 3 Either enter the regular expression in the Value field, or click Build to get help creating the expression.
The regular expression is limited to 100 characters in length.
If you click Build, use the following process to create the expression:
a) In the Build Snippet area, create a component of the expression using the following options. Look at the
Snippet Preview area at the end of this section to see the expression you are building.
• Starts at the beginning of the line (^)—Indicates that the snippet should start at the beginning of a
line, using the caret (^) metacharacter. Be sure to insert any snippet with this option at the beginning
of the regular expression.
• Specify Character String—If you are trying to match a specific string, such as a word or phrase, enter
the string.
If there are any metacharacters in your text string that you want to be used literally, choose Escape
Special Characters to add the backslash (\) escape character before them. for example, if you enter
“example.com,” this option converts it to “example\.com”.
294
If you want to match upper and lower case characters, choose Ignore Case. For example, “cats” is
converted to “[cC][aA][tT][sS]”.
• Specify Character—If you are trying to match a specific type of character or set of characters, rather
than a particular phrase, select this option and identify the characters using these options:
◦Negate the character—Specifies not to match the character you identify.
◦Any character (.)—Inserts the period (.) metacharacter to match any character. For example,
d.g matches dog, dag, dtg, and any word that contains those characters, such as doggonnit.
◦Character set—Inserts a character set. Text can match any character in the set. For example,
if you specify [0-9A-Za-z], then this snippet will match any character from A to Z (upper or
lower case) or any digit 0 through 9. The [\n\f\r\t] set matches a new line, form feed, carriage
return, or a tab.
◦Special character—Inserts a character that requires an escape, including \, ?, *, +, |, ., [, (, or
^. The escape character is the backslash (\), which is automatically entered when you choose
this option.
◦Whitespace character—Whitespace characters include \n (new line), \f (form feed), \r (carriage
return), or \t (tab).
◦Three digit octal number—Matches an ASCII character as octal (up to three digits). For
example, the character \040 represents a space. The backslash (\) is entered automatically.
◦Two digit hexadecimal number—Matches an ASCII character using hexadecimal (exactly
two digits). The backslash (\) is entered automatically.
◦Specified character—Enter any single character.
b) Add the snippet to the regular expression box using one of the following buttons. Note that you can also
type directly in the regular expression.
• Append Snippet—Adds the snippet to the end of the regular expression.
• Append Snippet as Alternate—Adds the snippet to the end of the regular expression separated by
a pipe (|), which matches either expression it separates. For example, dog|cat matches dog or cat.
• Insert Snippet at Cursor—Inserts the snippet at the cursor.
c) Repeat the process to add snippets until the expression is complete.

d) (Optional.) In Selection Occurrences, select how often the expression or parts of it must match text to
be considered a match. Select text in the Regular Expression field, click one of the following options, and
then click Apply to Selection. For example, if the regular expression is “test me,” and you select “me” and
apply One or more times, then the regular expression changes to “test (me)+”.
• Zero or one times (?)—There are 0 or 1 of the previous expression. For example, lo?se matches lse
or lose.
• One or more times (+)—There is at least 1 of the previous expression. For example, lo+se matches
lose and loose, but not lse.
• Any number of times (*)—There are 0, 1 or any number of the previous expression. For example,
lo*se matches lse, lose, loose, and so on.
295
Monitoring Inspection Policies
• At least—Repeat at least x times. For example, ab(xy){2,}z matches abxyxyz, abxyxyxyz, and so
on.
• Exactly—Repeat exactly x times. For example, ab(xy){3}z matches abxyxyxyz.
e) Click Test to verify your expression will match the intended text. If the test is unsuccessful, you can try
editing it in the test dialog, or return to the expression builder. If you edit the expression in the text dialog
and click OK, the edits are saved and reflected in the expression builder.
f) Click OK.
Create a Regular Expression Class Map

A regular expression class map identifies one or more regular expression. It is simply a collection of regular
expression objects. You can use a regular expression class map in many cases in replace of a regular expression
object.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Regular Expressions.
Step 2 In the Regular Expressions Classes area, do one of the following:
• Choose Add to add a new class map. Enter a name and optionally, a description.
• Choose an existing class map and click Edit.
Step 3 Select the expressions you want in the map and click Add. Remove any you do not want.
Step 4 Click OK.
Monitoring Inspection Policies

To monitor inspection service policies, enter the following commands. Select Tools > Command Line
Interface to enter these commands. See the command reference on Cisco.com for detailed syntax and examples.
• show service-policy inspect protocol
Displays statistics for inspection service policies. The protocol is the protocol from the inspect command,
for example dns. However, not all inspection protocols show statistics with this command. For example:
asa# show service-policy inspect dns
Global policy:
Class-map: inspection_default
Inspect: dns preset_dns_map, packet 0, lock fail 0, drop 0, reset-drop 0,
5-min-pkt-rate 0 pkts/sec, v6-fail-close 0
message-length maximum client auto, drop 0
message-length maximum 512, drop 0
dns-guard, count 0
296
History for Application Inspection
protocol-enforcement, drop 0
nat-rewrite, count 0
asa#
• show conn
Shows current connections for traffic passing through the device. This command has a wide range of
keywords so that you can get information about various protocols.
• Additional commands for specific inspected protocols:
◦show ctiqbe
Displays information about the media connections allocated by the CTIQBE inspection engine
◦show h225
Displays information for H.225 sessions.
◦show h245
Displays information for H.245 sessions established by endpoints using slow start.
◦show h323 ras
Displays connection information for H.323 RAS sessions established between a gatekeeper and
its H.323 endpoint.
◦show mgcp {commands | sessions }
Displays the number of MGCP commands in the command queue or the number of existing MGCP
sessions.
◦show sip
Displays information for SIP sessions.
◦show skinny
Displays information for Skinny (SCCP) sessions.
◦show sunrpc-server active
Displays the pinholes opened for Sun RPC services.

Inspection policy maps 7.2(1) The inspection policy map was introduced. The following
command was introduced: class-map type inspect.
Regular expressions and policy maps 7.2(1) Regular expressions and policy maps were introduced to be
used under inspection policy maps. The following commands
were introduced: class-map type regex, regex, match regex.
Match any for inspection policy maps 8.0(2) The match any keyword was introduced for use with inspection
policy maps: traffic can match one or more criteria to match
the class map. Formerly, only match all was available.
297
298
CHAPTER 13
Inspection of Basic Internet Protocols
The following topics explain application inspection for basic Internet protocols. For information on why you
need to use inspection for certain protocols, and the overall methods for applying inspection, see Getting
Started with Application Layer Protocol Inspection, on page 281.
• DCERPC Inspection, page 300

• DNS Inspection, page 302
• FTP Inspection, page 305
• HTTP Inspection, page 309
• ICMP Inspection, page 313
• ICMP Error Inspection, page 313
• ILS Inspection, page 314
• Instant Messaging Inspection, page 314
• IP Options Inspection, page 316
• IPsec Pass Through Inspection, page 318
• IPv6 Inspection, page 319
• NetBIOS Inspection, page 320
• PPTP Inspection, page 321
• RSH Inspection, page 321
• SMTP and Extended SMTP Inspection, page 322
• SNMP Inspection, page 325
• SQL*Net Inspection, page 326
• Sun RPC Inspection, page 326
• TFTP Inspection, page 328
• XDMCP Inspection, page 328
• VXLAN Inspection, page 329
299
DCERPC Inspection
• History for Basic Internet Protocol Inspection, page 329
DCERPC Inspection
DCERPC inspection is not enabled in the default inspection policy, so you must enable it if you need this
inspection. You can simply edit the default global inspection policy to add DCERPC inspection. You can
alternatively create a new service policy as desired, for example, an interface-specific policy.
The following sections describe the DCERPC inspection engine.
DCERPC Overview
Microsoft Remote Procedure Call (MSRPC), based on DCERPC, is a protocol widely used by Microsoft
distributed client and server applications that allows software clients to execute programs on a server remotely.
This typically involves a client querying a server called the Endpoint Mapper listening on a well known port
number for the dynamically allocated network information of a required service. The client then sets up a
secondary connection to the server instance providing the service. The security appliance allows the appropriate
port number and network address and also applies NAT, if needed, for the secondary connection.
The DCERPC inspection engine inspects for native TCP communication between the EPM and client on well
known TCP port 135. Map and lookup operations of the EPM are supported for clients. Client and server can
be located in any security zone. The embedded server IP address and Port number are received from the
applicable EPM response messages. Since a client may attempt multiple connections to the server port returned
by EPM, multiple use of pinholes are allowed, which have configurable timeouts.
DCE inspection supports the following universally unique identifiers (UUIDs) and messages:
• End point mapper (EPM) UUID. All EPM messages are supported.
• ISystemMapper UUID (non-EPM). Supported messages are:
◦RemoteCreateInstance opnum4
◦RemoteGetClassObject opnum3
• OxidResolver UUID (non-EPM). Supported message is:

◦ServerAlive2 opnum5
• Any message that does not contain an IP address or port information because these messages do not
require inspection.
Configure a DCERPC Inspection Policy Map

To specify additional DCERPC inspection parameters, create a DCERPC inspection policy map. You can
then apply the inspection policy map when you enable DCERPC inspection.
When defining traffic matching criteria, you can either create a class map or include the match statements
directly in the policy map. The difference between creating a class map and defining the traffic match directly
in the inspection policy map is that you can reuse class maps. The following procedure covers inspection
policy maps, but also explains the traffic matching criteria available in the class map. To create a class map,
select Configuration > Firewall > Objects > Class Maps > DCERPC.
300
DCERPC Inspection
Tip You can configure inspection maps while creating service policies, in addition to the procedure explained
below. The contents of the map are the same regardless of how you create it.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > DCERPC.
• Click Add to add a new map.
• Select a map to view its contents. You can change the security level directly, or click Customize to edit
the map. The remainder of the procedure assumes you are customizing or adding a map.
Step 3 For new maps, enter a name (up to 40 characters) and description. When editing a map, you can change the
description only.
Step 4 In the Security Level view of the DCERPC Inspect Map dialog box, select the level that best matches your
desired configuration.
If one of the preset levels matches your requirements, you are now done. Just click OK, skip the rest of this
procedure, and use the map in a service policy rule for DCERPC inspection.
If you need to customize the settings further, click Details and continue with the procedure.
Tip The UUID Filtering button is a shortcut to configure message filtering, which is explained later in
this procedure.
Step 5 Configure the desired options.
• Pinhole Timeout—Sets the pinhole timeout. Because a client may use the server information returned
by the endpoint mapper for multiple connections, the timeout value is configurable based on the client
application environment. Range is from 0:0:1 to 1193:0:0.
• Enforce endpoint-mapper service—Whether to enforce the endpoint mapper service during binding
so that only its service traffic is processed.
• Enable endpoint-mapper service lookup—Whether to enable the lookup operation of the endpoint
mapper service. You can also enforce a timeout for the service lookup. If you do not configure a timeout,
the pinhole timeout is used.
Step 6 (Optional.) Click the Inspections tab and define the actions to take for specific types of messages.
You can define traffic matching criteria based on DCERPC class maps, by configuring matches directly in
the inspection map, or both.
a) Do any of the following:
• Click Add to add a new criterion.
• Select an existing criterion and click Edit.
b) Choose Single Match to define the criterion directly, or Multiple Match, in which case you select the
DCERPC class map that defines the criteria.
c) If you are defining the criterion here, choose the match type for the criteria: Match (traffic must match
the criterion) or No Match (traffic must not match the criterion). Then, select the desired UUID:
301
DNS Inspection
• ms-rpc-epm—Matches Microsoft RPC EPM messages.

• ms-rpc-isystemactivator—Matches ISystemMapper messages.
• ms-rpc-oxidresolver—Matches OxidResolver messages.
d) Choose whether to Reset or Log the connection. You can also enable logging if you elect to reset the
connection. Resetting the connection drops the packet, closes the connection, and sends a TCP reset to
the server or client.
e) Click OK to add the criterion. Repeat the process as needed.
Step 7 Click OK.
You can now use the inspection map in a DCERPC inspection service policy.
What to Do Next
You can now configure an inspection policy to use the map. See Configure Application Layer Protocol
DNS Inspection
DNS inspection is enabled by default. You need to configure it only if you want non-default processing. The
following sections describe DNS application inspection.
Defaults for DNS Inspection

DNS inspection is enabled by default, using the preset_dns_map inspection class map:
• The maximum DNS message length is 512 bytes.
• The maximum client DNS message length is automatically set to match the Resource Record.
• DNS Guard is enabled, so the ASA tears down the DNS session associated with a DNS query as soon
as the DNS reply is forwarded by the ASA. The ASA also monitors the message exchange to ensure
that the ID of the DNS reply matches the ID of the DNS query.
• Translation of the DNS record based on the NAT configuration is enabled.
• Protocol enforcement is enabled, which enables DNS message format check, including domain name
length of no more than 255 characters, label length of 63 characters, compression, and looped pointer
check.
Configure DNS Inspection Policy Map

You can create a DNS inspection policy map to customize DNS inspection actions if the default inspection
behavior is not sufficient for your network.
You can optionally create a DNS inspection class map to define the traffic class for DNS inspection. The
other option is to define the traffic classes directly in the DNS inspection policy map. The difference between
creating a class map and defining the traffic match directly in the inspection map is that you can create more
complex match criteria and you can reuse class maps. Although this procedure explains inspection maps, the
302
DNS Inspection
matching criteria used in class maps are the same as those explained in the step relating to the Inspection tab.
You can configure DNS class maps by selecting Configuration > Firewall > Objects > Class Maps >
DNS, or by creating them while configuring the inspection map.
Before You Begin

Some traffic matching options use regular expressions for matching purposes. If you intend to use one of
those techniques, first create the regular expression or regular expression class map.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > DNS.
description only.
Step 4 In the Security Level view of the DNS Inspect Map dialog box, select the level that best matches your desired
configuration. The default level is Low.
procedure, and use the map in a service policy rule for DNS inspection.
If you need to customize the settings further, click Details, and continue with the procedure.
Step 5 Click the Protocol Conformance tab and choose the desired options:
• Enable DNS guard function—Using DNS Guard, the ASA tears down the DNS session associated
with a DNS query as soon as the DNS reply is forwarded by the ASA. The ASA also monitors the
message exchange to ensure that the ID of the DNS reply matches the ID of the DNS query.
• Enable NAT re-write function—Translates the DNS record based on the NAT configuration.
• Enable protocol enforcement—Enables DNS message format check, including domain name length
of no more than 255 characters, label length of 63 characters, compression, and looped pointer check.
• Randomize the DNS identifier for DNS query.
• Enforce TSIG resource record to be present in DNS message—You can drop or log non-conforming
packets, and optionally log dropped packets.
Step 6 Click the Filtering tab and choose the desired options.
• Global Settings—Choose whether to drop packets that exceed the specified maximum length regardless
of whether they are from the client or server, from 512 to 65535 bytes.
303
DNS Inspection
• Server Settings—Drop packets that exceed specified maximum length and Drop packets sent to
server that exceed length indicated by the RR—Sets the maximum server DNS message length, from
512 to 65535 bytes, or sets the maximum length to the value in the Resource Record. If you enable both
settings, the lower value is used.
• Client Settings—Drop packets that exceed specified maximum length and Drop packets sent to
server that exceed length indicated by the RR—Sets the maximum client DNS message length, from
512 to 65535 bytes, or sets the maximum length to the value in the Resource Record. If you enable both
settings, the lower value is used.
Step 7 Click the Mismatch Rate tab and choose whether to enable logging when the DNS ID mismatch rate exceeds
the specified threshold. For example, you could set a threshold of 30 mismatches per 3 seconds.
Step 8 Click the Inspections tab and define the specific inspections you want to implement based on traffic
characteristics.
You can define traffic matching criteria based on DNS class maps, by configuring matches directly in the
inspection map, or both.
DNS class map that defines the criteria.
the criterion) or No Match (traffic must not match the criterion). For example, if No Match is selected on
the string “example.com,” then any traffic that contains “example.com” is excluded from the class map.
Then, configure the criterion as follows:
• Header Flag—Select whether the flag should equal or contain the specified value, then either select
the header flag name, or enter the hex value of the header (0x0 to 0xfff). If you select multiple header
values, “equals” requires that all flags are present, “contains” that any one of the flags is present, in
the packet. Header flag names are AA (Authoritative Answer), QR (Query), RA (Recursion Available),
RD (Recursion Desired), TC (Truncation).
• Type—The DNS Type field name or value in the packet. Field names are A (IPv4 address), AXFR
(full zone transfer), CNAME (canonical name), IXFR (incremental zone transfer), NS (authoritative
name server), SOA (start of a zone of authority) or TSIG (transaction signature). Values are arbitrary
numbers in the DNS Type field from 0 to 65535: either enter a specific value or a range of values.
• Class—The DNS Class field name or value in the packet. Internet is the only possible field name.
Values are arbitrary numbers in the DNS Class field from 0 to 65535: either enter a specific value
or a range of values.
• Question—The question portion of a DNS message.
• Resource Record—The DNS resource record. Choose whether to match the additional, answer, or
authority resource record section.
d) Choose the primary action to take for matching traffic: drop packet, drop connection, mask (for Header
Flag matches only) or none.
e) Choose whether to enable or disable logging. You must disable logging if you want to enforce TSIG.
304
FTP Inspection
f) Chose whether to enforce the presence of a TSIG resource record. You can drop the packet, log it, or drop
and log it. Usually, you must select Primary Action: None and Log: Disable to enforce TSIG. However,
for Header Flag matches, you can enforce TSIG along with the mask primary action.
g) Click OK to add the inspection. Repeat the process as needed.
Step 9 Click OK in the DNS Inspect Map dialog box.
You can now use the inspection map in a DNS inspection service policy.
What to Do Next
FTP Inspection
FTP inspection is enabled by default. You need to configure it only if you want non-default processing. The
following sections describe the FTP inspection engine.
FTP Inspection Overview

The FTP application inspection inspects the FTP sessions and performs four tasks:
• Prepares dynamic secondary data connection channels for FTP data transfer. Ports for these channels
are negotiated through PORT or PASV commands. The channels are allocated in response to a file
upload, a file download, or a directory listing event.
• Tracks the FTP command-response sequence.
• Generates an audit trail.
◦Audit record 303002 is generated for each file that is retrieved or uploaded.
◦Audit record 201005 is generated if the secondary dynamic channel preparation failed due to
memory shortage.
• Translates the embedded IP address.
Note If you disable FTP inspection, outbound users can start connections only in passive mode, and all inbound
FTP is disabled.
Strict FTP
Strict FTP increases the security of protected networks by preventing web browsers from sending embedded
commands in FTP requests. To enable strict FTP, click the Configure button next to FTP on the Configuration
> Firewall > Service Policy Rules > Edit Service Policy Rule > Rule Actions > Protocol Inspection tab.
305
FTP Inspection
When you use strict FTP, you can optionally specify an FTP inspection policy map to specify FTP commands
that are not permitted to pass through the ASA.
Strict FTP inspection enforces the following behavior:
• An FTP command must be acknowledged before the ASA allows a new command.
• The ASA drops connections that send embedded commands.
• The 227 and PORT commands are checked to ensure they do not appear in an error string.
Caution Using strict FTP may cause the failure of FTP clients that are not strictly compliant with FTP RFCs.
With strict FTP inspection, each FTP command and response sequence is tracked for the following anomalous
activity:
• Truncated command—Number of commas in the PORT and PASV reply command is checked to see
if it is five. If it is not five, then the PORT command is assumed to be truncated and the TCP connection
is closed.
• Incorrect command—Checks the FTP command to see if it ends with <CR><LF> characters, as required
by the RFC. If it does not, the connection is closed.
• Size of RETR and STOR commands—These are checked against a fixed constant. If the size is greater,
then an error message is logged and the connection is closed.
• Command spoofing—The PORT command should always be sent from the client. The TCP connection
is denied if a PORT command is sent from the server.
• Reply spoofing—PASV reply command (227) should always be sent from the server. The TCP connection
is denied if a PASV reply command is sent from the client. This prevents the security hole when the
user executes “227 xxxxx a1, a2, a3, a4, p1, p2.”
• TCP stream editing—The ASA closes the connection if it detects TCP stream editing.
• Invalid port negotiation—The negotiated dynamic port value is checked to see if it is less than 1024. As
port numbers in the range from 1 to 1024 are reserved for well-known connections, if the negotiated
port falls in this range, then the TCP connection is freed.
• Command pipelining—The number of characters present after the port numbers in the PORT and PASV
reply command is cross checked with a constant value of 8. If it is more than 8, then the TCP connection
is closed.
• The ASA replaces the FTP server response to the SYST command with a series of Xs to prevent the
server from revealing its system type to FTP clients. To override this default behavior, use the no
mask-syst-reply command in the FTP map.
Configure an FTP Inspection Policy Map

FTP command filtering and security checks are provided using strict FTP inspection for improved security
and control. Protocol conformance includes packet length checks, delimiters and packet format checks,
command terminator checks, and command validation.
306
FTP Inspection
Blocking FTP based on user values is also supported so that it is possible for FTP sites to post files for
download, but restrict access to certain users. You can block FTP connections based on file type, server name,
and other attributes. System message logs are generated if an FTP connection is denied after inspection.
If you want FTP inspection to allow FTP servers to reveal their system type to FTP clients, and limit the
allowed FTP commands, then create and configure an FTP inspection policy map. You can then apply the
map when you enable FTP inspection.
You can optionally create an FTP inspection class map to define the traffic class for FTP inspection. The other
option is to define the traffic classes directly in the FTP inspection policy map. The difference between creating
a class map and defining the traffic match directly in the inspection map is that you can create more complex
match criteria and you can reuse class maps. Although this procedure explains inspection maps, the matching
criteria used in class maps are the same as those explained in the step relating to the Inspection tab. You can
configure DNS class maps by selecting Configuration > Firewall > Objects > Class Maps > FTP, or
by creating them while configuring the inspection map.
Before You Begin

Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > FTP.
description only.
Step 4 In the Security Level view of the FTP Inspect Map dialog box, select the level that best matches your desired
configuration. The default level is High.
procedure, and use the map in a service policy rule for FTP inspection.
Tip The File Type Filtering button is a shortcut to configure file media or MIME type inspection, which
is explained later in this procedure.
Step 5 Click the Parameters tab and choose whether to mask the greeting banner from the server or mask the reply
to the SYST command.
Masking these items prevents the client from discovering server information that might be helpful in an attack.
characteristics.
307
FTP Inspection
You can define traffic matching criteria based on FTP class maps, by configuring matches directly in the
FTP class map that defines the criteria.
• File Name—Match the name of the file being transferred against the selected regular expression or
regular expression class.
• File Type—Match the MIME or media type of the file being transferred against the selected regular
expression or regular expression class.
• Server—Match the FTP server name against the selected regular expression or regular expression
class.
• User—Match the name of the logged-in user against the selected regular expression or regular
expression class.
• Request Command—The FTP command used in the packet, any combination of the following:
◦APPE—Append to a file.
◦CDUP—Changes to the parent directory of the current working directory.
◦DELE—Delete a file on the server.
◦GET—Gets a file from the server.
◦HELP—Provides help information.
◦MKD—Makes a directory on the server.
◦PUT—Sends a file to the server.
◦RMD—Deletes a directory on the server.
◦RNFR—Specifies the “rename-from” filename.
◦RNTO—Specifies the “rename-to” filename.
◦SITE—Used to specify a server-specific command. This is usually used for remote
administration.
◦STOU—Stores a file using a unique file name.
d) Choose whether to enable or disable logging. The action is always to reset the connection, which drops
the packet, closes the connection, and sends a TCP reset to the server or client.
308
HTTP Inspection
e) Click OK to add the inspection. Repeat the process as needed.

Step 7 Click OK in the FTP Inspect Map dialog box.
You can now use the inspection map in a FTP inspection service policy.
What to Do Next
HTTP Inspection
If you are not using a purpose-built module for HTTP inspection and application filtering, such as ASA CX
or ASA FirePOWER, you can manually configure HTTP inspection on the ASA.
HTTP inspection is not enabled in the default inspection policy, so you must enable it if you need this inspection.
However, the default inspect class does include the default HTTP ports, so you can simply edit the default
global inspection policy to add HTTP inspection. You can alternatively create a new service policy as desired,
for example, an interface-specific policy.
Tip Do not configure HTTP inspection in both a service module and on the ASA, as the inspections are not
compatible.
The following sections describe the HTTP inspection engine.
HTTP Inspection Overview
Tip You can install a service module that performs application and URL filtering, which includes HTTP
inspection, such as ASA CX or ASA FirePOWER. The HTTP inspection running on the ASA is not
compatible with these modules. Note that it is far easier to configure application filtering using a
purpose-built module rather than trying to manually configure it on the ASA using an HTTP inspection
policy map.
Use the HTTP inspection engine to protect against specific attacks and other threats that are associated with
HTTP traffic.
HTTP application inspection scans HTTP headers and body, and performs various checks on the data. These
checks prevent various HTTP constructs, content types, and tunneling and messaging protocols from traversing
the security appliance.
The enhanced HTTP inspection feature, which is also known as an application firewall and is available when
you configure an HTTP inspection policy map, can help prevent attackers from using HTTP messages for
circumventing network security policy.
HTTP application inspection can block tunneled applications and non-ASCII characters in HTTP requests
and responses, preventing malicious content from reaching the web server. Size limiting of various elements
in HTTP request and response headers, URL blocking, and HTTP server header type spoofing are also
supported.
309
HTTP Inspection
Enhanced HTTP inspection verifies the following for all HTTP messages:
• Conformance to RFC 2616
• Use of RFC-defined methods only.
• Compliance with the additional criteria.
Configure an HTTP Inspection Policy Map

To specify actions when a message violates a parameter, create an HTTP inspection policy map. You can
then apply the inspection policy map when you enable HTTP inspection.
You can optionally create an HTTP inspection class map to define the traffic class for HTTP inspection. The
other option is to define the traffic classes directly in the HTTP inspection policy map. The difference between
You can configure HTTP class maps by selecting Configuration > Firewall > Objects > Class Maps
> HTTP, or by creating them while configuring the inspection map.
Before You Begin

Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > HTTP.
description only.
Step 4 In the Security Level view of the HTTP Inspect Map dialog box, select the level that best matches your
desired configuration. The default level is Low.
procedure, and use the map in a service policy rule for HTTP inspection.
Tip The URI Filtering button is a shortcut to configure Request URI inspection, which is explained later
in this procedure.
Step 5 Click the Parameters tab and configure the desired options.
310
HTTP Inspection
• Body Match Maximum—The maximum number of characters in the body of an HTTP message that
should be searched in a body match. Default is 200 bytes. A large number will have a significant impact
on performance.
• Check for protocol violations—Whether to verify that packets conform to the HTTP protocol. For
violations, you can drop the connection, reset it, or log it. When dropping or resetting, you can also
enable logging.
• Spoof server string—Replaces the server HTTP header value with the specified string, up to 82
characters.
characteristics.
You can define traffic matching criteria based on HTTP class maps, by configuring matches directly in the
HTTP class map that defines the criteria.
• Request/Response Content Type Mismatch—Match packets where the content type in the response
does not match one of the MIME types in the accept field of the request.
• Request Arguments—Match the arguments of the request against the selected regular expression or
• Request Body Length—Match packets where the body of the request is greater than the specified
number of bytes.
• Request Body—Match the body of the request against the selected regular expression or regular
expression class.
• Request Header Field Count—Match packets where the number of header fields in the request is
greater than the specified count. You can match the field header type to a regular expression or to a
predefined type. The predefined types are: accept, accept-charset, accept-encoding, accept-language,
allow, authorization, cache-control, connection, content-encoding, content-language, content-length,
content-location, content-md5, content-range, content-type, cookie, date, expect, expires, from, host,
if-match, if-modified-since, if-none-match, if-range, if-unmodified-since, last-modified, max-forwards,
pragma, proxy-authorization, range, referer, te, trailer, transfer-encoding, upgrade, user-agent, via,
warning.
• Request Header Field Length—Match packets where the length of the header field in the request is
greater than the specified bytes. You can match the field header type to a regular expression or to a
predefined type. The predefined types are listed above for Request Header Field Count.
311
HTTP Inspection
• Request Header Field—Match the content of the selected header field in the request against the
selected regular expression or regular expression class. You can specify a predefined header type or
use a regular expression to select the headers.
• Request Header Count—Match packets where the number of headers in the request is greater than
the specified number.
• Request Header Length—Match packets where the length of the header in the request is greater than
the specified bytes.
• Request Header Non-ASCII—Match packets where the header in the request contains non-ASCII
characters.
• Request Method—Match packets where the request method matches the predefined type or the
selected regular expression or regular expression class. The predefined types are: bcopy, bdelete,
bmove, bpropfind, bproppatch, connect, copy, delete, edit, get, getattribute, getattributenames,
getproperties, head, index, lock, mkcol, mkdir, move, notify, options, poll, post, propfind, proppatch,
put, revadd, revlabel, revlog, revnum, save, search, setattribute, startrev, stoprev, subscribe, trace,
unedit, unlock, unsubscribe.
• Request URI Length—Match packets where the length of the URI of the request is greater than the
specified bytes.
• Request URI—Match the content of the URI of the request against the selected regular expression
or regular expression class.
• Request Body—Match the body of the request against the selected regular expression or regular
expression class, or to ActiveX or Java Applet content.
• Response Body Length—Match packets where the length of the body of the response is greater than
the specified bytes.
• Response Header Field Count—Match packets where the number of header fields in the response is
greater than the specified count. You can match the field header type to a regular expression or to a
predefined type. The predefined types are: accept-ranges, age, allow, cache-control, connection,
content-encoding, content-language, content-length, content-location, content-md5, content-range,
content-type, date, etag, expires, last-modified, location, pragma, proxy-authenticate, retry-after,
server, set-cookie, trailer, transfer-encoding, upgrade, vary, via, warning, www-authenticate.
• Response Header Field Length—Match packets where the length of the header field in the response
is greater than the specified bytes. You can match the field header type to a regular expression or to
a predefined type. The predefined types are listed above for Response Header Field Count.
• Response Header Field—Match the content of the selected header field in the response against the
selected regular expression or regular expression class. You can specify a predefined header type or
use a regular expression to select the headers.
• Response Header Count—Match packets where the number of headers in the response is greater
than the specified number.
• Response Header Length—Match packets where the length of the header in the response is greater
than the specified bytes.
• Response Header Non-ASCII—Match packets where the header in the response contains non-ASCII
characters.
312
ICMP Inspection
• Response Status Line—Match the content of the response status line against the selected regular
d) Choose whether to drop the connection, reset it, or log it. For drop connection and reset, you can enable
or disable logging.
Step 7 Click OK in the HTTP Inspect Map dialog box.
You can now use the inspection map in a HTTP inspection service policy.
What to Do Next
ICMP Inspection
The ICMP inspection engine allows ICMP traffic to have a “session” so it can be inspected like TCP and UDP
traffic. Without the ICMP inspection engine, we recommend that you do not allow ICMP through the ASA
in an ACL. Without stateful inspection, ICMP can be used to attack your network. The ICMP inspection
engine ensures that there is only one response for each request, and that the sequence number is correct.
However, ICMP traffic directed to an ASA interface is never inspected, even if you enable ICMP inspection.
Thus, a ping (echo request) to an interface can fail under specific circumstances, such as when the echo request
comes from a source that the ASA can reach through a backup default route.
For information on enabling ICMP inspection, see Configure Application Layer Protocol Inspection, on page
288.
ICMP Error Inspection

When ICMP Error inspection is enabled, the ASA creates translation sessions for intermediate hops that send
ICMP error messages, based on the NAT configuration. The ASA overwrites the packet with the translated
IP addresses.
When disabled, the ASA does not create translation sessions for intermediate nodes that generate ICMP error
messages. ICMP error messages generated by the intermediate nodes between the inside host and the ASA
reach the outside host without consuming any additional NAT resource. This is undesirable when an outside
host uses the traceroute command to trace the hops to the destination on the inside of the ASA. When the
ASA does not translate the intermediate hops, all the intermediate hops appear with the mapped destination
IP address.
For information on enabling ICMP Error inspection, see Configure Application Layer Protocol Inspection,
on page 288.
313
ILS Inspection
ILS Inspection
The Internet Locator Service (ILS) inspection engine provides NAT support for Microsoft NetMeeting,
SiteServer, and Active Directory products that use LDAP to exchange directory information with an ILS
server. You cannot use PAT with ILS inspection because only IP addresses are stored by an LDAP database.
For search responses, when the LDAP server is located outside, consider using NAT to allow internal peers
to communicate locally while registered to external LDAP servers. If you do not need to use NAT, we
recommend that you turn off the inspection engine to provide better performance.
Additional configuration may be necessary when the ILS server is located inside the ASA border. This would
require a hole for outside clients to access the LDAP server on the specified port, typically TCP 389.
Note Because ILS traffic (H225 call signaling) only occurs on the secondary UDP channel, the TCP connection
is disconnected after the TCP inactivity interval. By default, this interval is 60 minutes and can be adjusted
using the TCP timeout command. In ASDM, this is on the Configuration > Firewall > Advanced >
Global Timeouts pane.
ILS inspection has the following limitations:

• Referral requests and responses are not supported.
• Users in multiple directories are not unified.
• Single users having multiple identities in multiple directories cannot be recognized by NAT.
For information on enabling ILS inspection, see Configure Application Layer Protocol Inspection, on page
288.
Instant Messaging Inspection

The Instant Messaging (IM) inspect engine lets you control the network usage of IM and stop leakage of
confidential data, propagation of worms, and other threats to the corporate network.
IM inspection is not enabled in the default inspection policy, so you must enable it if you need this inspection.
However, the default inspect class does include the default IM ports, so you can simply edit the default global
inspection policy to add IM inspection. You can alternatively create a new service policy as desired, for
example, an interface-specific policy.
If you decide to implement IM inspection, you can also configure an IM inspection policy map to specify
actions when a message violates a parameter. The following procedure explains IM inspection policy maps.
You can optionally create an IM inspection class map to define the traffic class for IM inspection. The other
option is to define the traffic classes directly in the IM inspection policy map. The difference between creating
match criteria and you can reuse class maps. This procedure explains inspection maps, but class maps are
essentially the same, except that you do not specify the actions for matching traffic. You can configure IM
class maps by selecting Configuration > Firewall > Objects > Class Maps > Instant Messaging (IM).
314
Instant Messaging Inspection
Before You Begin

Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > Instant Messaging (IM).
description only.
Step 4 Define the specific inspections you want to implement based on traffic characteristics.
You can define traffic matching criteria based on IM class maps, by configuring matches directly in the
IM class map that defines the criteria. Click Manage to create new class maps.
Then, configure the criterion.
• Protocol—Match traffic of a specific IM protocol, such as Yahoo Messenger or MSN Messenger.
• Service—Match a specific IM service, such as chat, file transfer, web cam, voice chat, conference,
or games.
• Version—Match the version of the IM message against the selected regular expression or regular
expression class.
• Client Login Name—Match the source client login name of the IM message against the selected
regular expression or regular expression class.
• Client Peer Login Name—Match the destination peer login name of the IM message against the
selected regular expression or regular expression class.
• Source IP Address—Match the source IP address and mask.
• Destination IP Address—Match the destination IP address and mask.
315
IP Options Inspection
• Filename—Match the filename of the IM message against the selected regular expression or regular
expression class.
d) Choose whether to drop the connection, reset it, or log it. For drop connection and reset, you can enable
or disable logging.
Step 5 Click OK in the IM Inspect Map dialog box.
You can now use the inspection map in a IM inspection service policy.
What to Do Next
You can configure IP Options inspection to control which IP packets are allowed based on the contents of the
IP Options field in the packet header. You can drop packets that have unwanted options, clear the options
(and allow the packet), or allow the packet without change.
IP options provide control functions that are required in some situations but unnecessary for most common
communications. In particular, IP options include provisions for time stamps, security, and special routing.
Use of IP Options is optional, and the field can contain zero, one, or more options.
For a list of IP options, with references to the relevant RFCs, see the IANA page, http://www.iana.org/
assignments/ip-parameters/ip-parameters.xhtml.
IP options inspection is enabled by default. You need to configure it only if you want to allow additional
options than the default map allows.
The following sections describe IP Options inspection.
Defaults for IP Options Inspection

IP Options inspection is enabled by default, using the _default_ip_options_map inspection policy map.
• The Router Alert option is allowed.
This option notifies transit routers to inspect the contents of the packet even when the packet is not
destined for that router. This inspection is valuable when implementing RSVP and similar protocols that
require relatively complex processing from the routers along the packet’s delivery path. Dropping RSVP
packets containing the Router Alert option can cause problems in VoIP implementations.
• Packets that contain any other options are dropped.
Each time a packet is dropped due to inspection, syslog 106012 is issued. The message shows which
option caused the drop. Use the show service-policy inspect ip-options command to view statistics for
each option.
316
Configure an IP Options Inspection Policy Map

If you want to perform non-default IP options inspection, create an IP options inspection policy map to specify
how you want to handle each option type.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > IP Options.
description only.
Step 4 Choose which options you want to allow by moving them from the Drop list to the Allow list.
Consider the following tips:
• The “default” option sets the default behavior for options not included in the map. If you move it to the
Allowed list, even options shown in the Drop list will be allowed.
• For any option you allow, you can check the Clear box to remove the option from the packet header
before transmitting the packet.
• Some options are listed by option type number. The number is the whole option type octet (copy, class,
and option number), not just the option number portion of the octet. These option types might not
represent real options. Non-standard options must be in the expected type-length-value format defined
in the Internet Protocol RFC 791, http://tools.ietf.org/html/rfc791.
• If a packet includes more than one type of option, it is dropped so long as the action for one of those
types is to drop the packet.
For a list of IP options, with references to the relevant RFCs, see the IANA page, http://www.iana.org/
assignments/ip-parameters/ip-parameters.xhtml.
Step 5 Click OK.

You can now use the inspection map in an IP options inspection service policy.
What to Do Next
317
IPsec Pass Through Inspection
IPsec Pass Through Inspection

IPsec Pass Through inspection is not enabled in the default inspection policy, so you must enable it if you
need this inspection. However, the default inspect class does include the default IPsec ports, so you can simply
edit the default global inspection policy to add IPsec inspection. You can alternatively create a new service
policy as desired, for example, an interface-specific policy.
The following sections describe the IPsec Pass Through inspection engine.
IPsec Pass Through Inspection Overview

Internet Protocol Security (IPsec) is a protocol suite for securing IP communications by authenticating and
encrypting each IP packet of a data stream. IPsec also includes protocols for establishing mutual authentication
between agents at the beginning of the session and negotiation of cryptographic keys to be used during the
session. IPsec can be used to protect data flows between a pair of hosts (for example, computer users or
servers), between a pair of security gateways (such as routers or firewalls), or between a security gateway and
a host.
IPsec Pass Through application inspection provides convenient traversal of ESP (IP protocol 50) and AH (IP
protocol 51) traffic associated with an IKE UDP port 500 connection. It avoids lengthy ACL configuration
to permit ESP and AH traffic and also provides security using timeout and max connections.
Configure a policy map for IPsec Pass Through to specify the restrictions for ESP or AH traffic. You can set
the per client max connections and the idle timeout.
NAT and non-NAT traffic is permitted. However, PAT is not supported.
Configure an IPsec Pass Through Inspection Policy Map

An IPsec Pass Through map lets you change the default configuration values used for IPsec Pass Through
application inspection. You can use an IPsec Pass Through map to permit certain flows without using an ACL.
The configuration includes a default map, _default_ipsec_passthru_map, that sets no maximum limit on ESP
connections per client, and sets the ESP idle timeout at 10 minutes. You need to configure an inspection policy
map only if you want different values, or if you want to set AH values.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > IPsec Pass Through.
318
IPv6 Inspection
description only.
Step 4 In the Security Level view of the IPsec Pass Through Inspect Map dialog box, select the level that best
matches your desired configuration.
procedure, and use the map in a service policy rule for IPsec Pass Through inspection.
Step 5 Choose whether to allow ESP and AH tunnels.

For each protocol, you can also set the maximum number of connections allowed per client, and the idle
timeout.
Step 6 Click OK.

You can now use the inspection map in an IPsec Pass Through inspection service policy.
IPv6 Inspection
IPv6 inspection lets you selectively log or drop IPv6 traffic based on the extension header. In addition, IPv6
inspection can check conformance to RFC 2460 for type and order of extension headers in IPv6 packets.
IPv6 inspection is not enabled in the default inspection policy, so you must enable it if you need this inspection.
You can simply edit the default global inspection policy to add IPv6 inspection. You can alternatively create
a new service policy as desired, for example, an interface-specific policy.
Defaults for IPv6 Inspection

If you enable IPv6 inspection and do not specify an inspection policy map, then the default IPv6 inspection
policy map is used, and the following actions are taken:
• Allows only known IPv6 extension headers. Non-conforming packets are dropped and logged.
• Enforces the order of IPv6 extension headers as defined in the RFC 2460 specification. Non-conforming
packets are dropped and logged.
• Drops any packet with a routing type header.
Configure an IPv6 Inspection Policy Map

To identify extension headers to drop or log, or to disable packet verification, create an IPv6 inspection policy
map to be used by the service policy.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > IPv6.
319
NetBIOS Inspection
description only.
Step 4 Click the Enforcement tab and choose whether to permit only known IPv6 extension headers or to enforce
the order of IPv6 extension headers as defined in RFC 2460. Non-conforming packets are dropped and logged.
Step 5 (Optional) Click the Header Matches tab to identify traffic to drop or log based on the headers in IPv6
messages.
b) Choose the IPv6 extension header to match:

• Authentication (AH) header.
• Destination Options header.
• Encapsulating Security Payload (ESP) header.
• Fragment header.
• Hop-by-Hop Options header.
• Routing header—Specify either a single header type number or a range of numbers.
• Header count—Specify the maximum number of extension headers you will allow without dropping
or logging the packet.
• Routing header address count—Specify the maximum number of addresses in the type 0 routing
header you will allow without dropping or logging the packet.
c) Choose whether to drop or log the packet. If you drop the packet, you can also enable logging.
d) Click OK to add the inspection. Repeat the process as needed.
Step 6 Click OK in the IPv6 Inspect Map dialog box.
You can now use the inspection map in an IPv6 inspection service policy.
What to Do Next
NetBIOS Inspection
NetBIOS application inspection performs NAT for the embedded IP address in the NetBIOS name service
(NBNS) packets and NetBIOS datagram services packets. It also enforces protocol conformance, checking
the various count and length fields for consistency.
NetBIOS inspection is enabled by default. You can optionally create a policy map to drop or log NetBIOS
protocol violations. The following procedure explains how to configure a NetBIOS inspection policy map.
320
PPTP Inspection
Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > NetBIOS.
description only.
Step 4 Select Check for Protocol Violations. There is no reason to create a map if you do not select this option.
Step 5 Select the action to take, either to drop the packet or log it. If you drop the packet, you can also enable logging.
Step 6 Click OK.
You can now use the inspection map in a NetBIOS inspection service policy.
What to Do Next
PPTP Inspection
PPTP is a protocol for tunneling PPP traffic. A PPTP session is composed of one TCP channel and usually
two PPTP GRE tunnels. The TCP channel is the control channel used for negotiating and managing the PPTP
GRE tunnels. The GRE tunnels carry PPP sessions between the two hosts.
When enabled, PPTP application inspection inspects PPTP protocol packets and dynamically creates the GRE
connections and xlates necessary to permit PPTP traffic.
Specifically, the ASA inspects the PPTP version announcements and the outgoing call request/response
sequence. Only PPTP Version 1, as defined in RFC 2637, is inspected. Further inspection on the TCP control
channel is disabled if the version announced by either side is not Version 1. In addition, the outgoing-call
request and reply sequence are tracked. Connections and xlates are dynamically allocated as necessary to
permit subsequent secondary GRE data traffic.
The PPTP inspection engine must be enabled for PPTP traffic to be translated by PAT. Additionally, PAT is
only performed for a modified version of GRE (RFC2637) and only if it is negotiated over the PPTP TCP
control channel. PAT is not performed for the unmodified version of GRE (RFC 1701 and RFC 1702).
For information on enabling PPTP inspection, see Configure Application Layer Protocol Inspection, on page
288.
RSH Inspection
RSH inspection is enabled by default. The RSH protocol uses a TCP connection from the RSH client to the
RSH server on TCP port 514. The client and server negotiate the TCP port number where the client listens
for the STDERR output stream. RSH inspection supports NAT of the negotiated port number if necessary.
321
SMTP and Extended SMTP Inspection
For information on enabling RSH inspection, see Configure Application Layer Protocol Inspection, on page
288.

ESMTP inspection detects attacks, including spam, phising, malformed message attacks, and buffer
overflow/underflow attacks. It also provides support for application security and protocol conformance, which
enforces the sanity of the ESMTP messages as well as block senders/receivers, and block mail relay.
ESMTP inspection is enabled by default. You need to configure it only if you want different processing than
that provided by the default inspection map.
The following sections describe the ESMTP inspection engine.
SMTP and ESMTP Inspection Overview

Extended SMTP (ESMTP) application inspection provides improved protection against SMTP-based attacks
by restricting the types of SMTP commands that can pass through the ASA and by adding monitoring
capabilities. ESMTP is an enhancement to the SMTP protocol and is similar is most respects to SMTP.
ESMTP application inspection controls and reduces the commands that the user can use as well as the messages
that the server returns. ESMTP inspection performs three primary tasks:
• Restricts SMTP requests to seven basic SMTP commands and eight extended commands. Supported
commands are the following:
◦Extended SMTP—AUTH, EHLO, ETRN, HELP, SAML, SEND, SOML, STARTTLS, and VRFY.
◦SMTP (RFC 821)—DATA, HELO, MAIL, NOOP, QUIT, RCPT, RSET.
• Monitors the SMTP command-response sequence.

• Generates an audit trail—Audit record 108002 is generated when an invalid character embedded in the
mail address is replaced. For more information, see RFC 821.
ESMTP inspection monitors the command and response sequence for the following anomalous signatures:
• Truncated commands.
• Incorrect command termination (not terminated with <CR><LR>).
• The MAIL and RCPT commands specify who are the sender and the receiver of the mail. Mail addresses
are scanned for strange characters. The pipeline character (|) is deleted (changed to a blank space) and
“<” ‚”>” are only allowed if they are used to define a mail address (“>” must be preceded by “<”).
• Unexpected transition by the SMTP server.
• For unknown or unsupported commands, the inspection engine changes all the characters in the packet
to X, which are rejected by the internal server. This results in a message such as “500 Command unknown:
'XXX'.” Incomplete commands are discarded
Unsupported ESMTP commands are ATRN, ONEX, VERB, CHUNKING, and private extensions..
• TCP stream editing.
• Command pipelining.
322
Note With ESMTP inspection enabled, a Telnet session used for interactive SMTP may hang if the following
rules are not observed: SMTP commands must be at least four characters in length; they must be terminated
with carriage return and line feed; and you must wait for a response before issuing the next reply.
Defaults for ESMTP Inspection

ESMTP inspection is enabled by default, using the _default_esmtp_map inspection policy map.
• The server banner is masked. The ESMTP inspection engine changes the characters in the server SMTP
banner to asterisks except for the “2”, “0”, “0” characters. Carriage return (CR) and linefeed (LF) characters
are ignored.
• Encrypted connections are not allowed. The STARTTLS indication is removed from the session
connection attempt, forcing the client and server to negotiate a plain text session, which can be inspected.
• Special characters in sender and receiver address are not noticed, no action is taken.
• Connections with command line length greater than 512 are dropped and logged.
• Connections with more than 100 recipients are dropped and logged.
• Messages with body length greater than 998 bytes are logged.
• Connections with header line length greater than 998 are dropped and logged.
• Messages with MIME filenames greater than 255 characters are dropped and logged.
• EHLO reply parameters matching “others” are masked.
Configure an ESMTP Inspection Policy Map

To specify actions when a message violates a parameter, create an ESMTP inspection policy map. You can
then apply the inspection policy map when you enable ESMTP inspection.
Before You Begin

Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > ESMTP.
323
description only.
Step 4 In the Security Level view of the ESMTP Inspect Map dialog box, select the level that best matches your
desired configuration.
procedure, and use the map in a service policy rule for ESMTP inspection.
Tip The MIME File Type Filtering button is a shortcut to configure file type inspection, which is explained
later in this procedure.
Step 5 Click the Parameters tab and configure the desired options.
• Mask Server Banner—Whether to mask the banner from the ESMTP server.
• Encrypted Packet Inspection—Whether to allow ESMTP over TLS (encrypted connections) without
inspection. You can optionally log encrypted connections. The default is to inspect all traffic, which
strips the STARTTLS indication from any encrypted session connection attempt and forces a plain-text
connection.
Step 6 Click the Filtering tab and configure the desired options.
• Configure mail relay—Identifies a domain name for mail relay. You can either drop the connection
and optionally log it, or log it.
• Check for special characters—Identifies the action to take for messages that include the special
characters pipe (|), back quote, and NUL in the sender or receiver email addresses. You can either drop
the connection and optionally log it, or log it.
characteristics.
b) Choose the match type for the criteria: Match (traffic must match the criterion) or No Match (traffic must
not match the criterion). For example, if No Match is selected on the string “example.com,” then any traffic
that contains “example.com” is excluded from the class map. Then, configure the criterion:
• Body Length—Matches messages where the length of an ESMTP body message is greater than the
specified number of bytes.
• Body Line Length—Matches messages where the length of a line in an ESMTP body message is
greater than the specified number of bytes.
• Commands—Matches the command verb in the message. You can specify one or more of the
following commands: auth, data, ehlo, etrn, helo, help, mail, noop, quit, rcpt, rset, saml, soml, vrfy.
• Command Recipient Count—Matches messages where the number of recipients is greater than
the specified count.
• Command Line Length—Matches messages where the length of a line in the command verb is
greater than the specified number of bytes.
324
SNMP Inspection
• EHLO Reply Parameters—Matches ESMTP EHLO reply parameters. You can specify one or
more of the following parameters: 8bitmime, auth, binaryname, checkpoint, dsn, etrn, others,
pipelining, size, vrfy.
• Header Length—Matches messages where the length of an ESMTP header is greater than the
specified number of bytes.
• Header Line Length—Matches messages where the length of a line in an ESMTP header is greater
than the specified number of bytes.
• Header To: Fields Count—Matches messages where the number of To fields in the header is greater
than the specified number.
• Invalid Recipients Count—Matches messages where the number of invalid recipients is greater
than the specified count.
• MIME File Type—Matches the MIME or media file type against the specified regular expression
or regular expression class.
• MIME Filename Length—Matches messages where a file name is longer than the specified number
of bytes.
• MIME Encoding—Matches the MIME encoding type. You can specify one or more of the following
types: 7bit, 8bit, base64, binary, others, quoted-printable.
• Sender Address—Matches the sender email address against the specified regular expression or
• Sender Address Length—Matches messages where the sender address is greater than the specified
number of bytes.
c) Choose whether to drop the connection, reset it, or log it. For drop connection and reset, you can enable
or disable logging. For command and EHLO reply parameter matching, you can also mask the command.
For command matching, you can also apply a rate limit in packets per second.
Step 8 Click OK in the ESMTP Inspect Map dialog box.
You can now use the inspection map in a ESMTP inspection service policy.
What to Do Next
SNMP Inspection
SNMP application inspection lets you restrict SNMP traffic to a specific version of SNMP. Earlier versions
of SNMP are less secure; therefore, denying certain SNMP versions may be required by your security policy.
The ASA can deny SNMP versions 1, 2, 2c, or 3. You control the versions permitted by creating an SNMP
map.
325
SQL*Net Inspection
SNMP inspection is not enabled in the default inspection policy, so you must enable it if you need this
inspection. You can simply edit the default global inspection policy to add SNMP inspection. You can
alternatively create a new service policy as desired, for example, an interface-specific policy.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > SNMP.
Step 2 Click Add, or select a map and click Edit. When adding a map, enter a map name.
Step 3 Select the SNMP versions to disallow.
Step 4 Click OK.
What to Do Next
SQL*Net Inspection
SQL*Net inspection is enabled by default. The inspection engine supports SQL*Net versions 1 and 2, but
only the Transparent Network Substrate (TNS) format. Inspection does not support the Tabular Data Stream
(TDS) format. SQL*Net messages are scanned for embedded addresses and ports, and NAT rewrite is applied
when necessary.
The default port assignment for SQL*Net is 1521. This is the value used by Oracle for SQL*Net, but this
value does not agree with IANA port assignments for Structured Query Language (SQL). If your application
uses a different port, apply the SQL*Net inspection to a traffic class that includes that port.
Note Disable SQL*Net inspection when SQL data transfer occurs on the same port as the SQL control TCP
port 1521. The security appliance acts as a proxy when SQL*Net inspection is enabled and reduces the
client window size from 65000 to about 16000 causing data transfer issues.
For information on enabling SQL*Net inspection, see Configure Application Layer Protocol Inspection, on
page 288.
Sun RPC Inspection

This section describes Sun RPC application inspection.
Sun RPC Inspection Overview

Sun RPC protocol inspection is enabled by default. You simply need to manage the Sun RPC server table to
identify which services are allowed to traverse the firewall. However, pinholing for NFS is done for any server
even without the server table configuration.
326
Sun RPC Inspection
Sun RPC is used by NFS and NIS. Sun RPC services can run on any port. When a client attempts to access
a Sun RPC service on a server, it must learn the port that service is running on. It does this by querying the
port mapper process, usually rpcbind, on the well-known port of 111.
The client sends the Sun RPC program number of the service and the port mapper process responds with the
port number of the service. The client sends its Sun RPC queries to the server, specifying the port identified
by the port mapper process. When the server replies, the ASA intercepts this packet and opens both embryonic
TCP and UDP connections on that port.
NAT or PAT of Sun RPC payload information is not supported.
Manage Sun RPC Services

Use the Sun RPC services table to control Sun RPC traffic based on established Sun RPC sessions.
Procedure
Step 1 Choose Configuration > Firewall > Advanced > SUNRPC Server.
• Click Add to add a new server.
• Select a server and click Edit.
Step 3 Configure the service properties:

• Interface Name—The interface through which traffic to the server flows.
• IP Address/Mask—The address of the Sun RPC server.
• Service ID—The service type on the server. To determine the service type (for example, 100003), use
the sunrpcinfo command at the UNIX or Linux command line on the Sun RPC server machine.
• Protocol—Whether the service uses TCP or UDP.
• Port/Port Range—The port or range of ports used by the service.
• Timeout—The idle timeout for the pinhole opened for the connection by Sun RPC inspection.
Step 4 Click OK.

Step 5 (Optional.) Monitor the pinholes created for these services.
To display the pinholes open for Sun RPC services, enter the show sunrpc-server active command. Select
Tools > Command Line Interface to enter the command. For example:
hostname# show sunrpc-server active

LOCAL FOREIGN SERVICE TIMEOUT
-----------------------------------------------
1 209.165.200.5/0 192.168.100.2/2049 100003 0:30:00
2 209.165.200.5/0 192.168.100.2/2049 100003 0:30:00
3 209.165.200.5/0 192.168.100.2/647 100005 0:30:00
4 209.165.200.5/0 192.168.100.2/650 100005 0:30:00
327
TFTP Inspection
The entry in the LOCAL column shows the IP address of the client or server on the inside interface, while
the value in the FOREIGN column shows the IP address of the client or server on the outside interface.
If necessary, you can clear these services using the clear sunrpc-server active
TFTP Inspection
TFTP inspection is enabled by default.
TFTP, described in RFC 1350, is a simple protocol to read and write files between a TFTP server and client.
The inspection engine inspects TFTP read request (RRQ), write request (WRQ), and error notification
(ERROR), and dynamically creates connections and translations, if necessary, to permit file transfer between
a TFTP client and server.
A dynamic secondary channel and a PAT translation, if necessary, are allocated on a reception of a valid read
(RRQ) or write (WRQ) request. This secondary channel is subsequently used by TFTP for file transfer or
error notification.
Only the TFTP server can initiate traffic over the secondary channel, and at most one incomplete secondary
channel can exist between the TFTP client and server. An error notification from the server closes the secondary
channel.
TFTP inspection must be enabled if static PAT is used to redirect TFTP traffic.
For information on enabling TFTP inspection, see Configure Application Layer Protocol Inspection, on page
288.
XDMCP Inspection
XDMCP inspection is enabled by default. XDMCP is a protocol that uses UDP port 177 to negotiate X
sessions, which use TCP when established.
For successful negotiation and start of an XWindows session, the ASA must allow the TCP back connection
from the Xhosted computer. To permit the back connection, you can use access rules to allow the TCP ports.
Alternatively, you can use the established command on the ASA. Once XDMCP negotiates the port to send
the display, the established command is consulted to verify if this back connection should be permitted.
During the XWindows session, the manager talks to the display Xserver on the well-known port 6000 | n.
Each display has a separate connection to the Xserver, as a result of the following terminal setting.
setenv DISPLAY Xserver:n
where n is the display number.

When XDMCP is used, the display is negotiated using IP addresses, which the ASA can NAT if needed.
XDCMP inspection does not support PAT.
For information on enabling XDMCP inspection, see Configure Application Layer Protocol Inspection, on
page 288.
328
VXLAN Inspection
VXLAN Inspection
Virtual Extensible Local Area Network (VXLAN) inspection works on VXLAN encapsulated traffic that
passes through the ASA. It ensures that the VXLAN header format conforms to standards, dropping any
malformed packets. VXLAN inspection is not done on traffic for which the ASA acts as a VXLAN Tunnel
End Point (VTEP) or a VXLAN gateway, as those checks are done as a normal part of decapsulating VXLAN
packets.
VXLAN packets are UDP, normally on port 4789. This port is part of the default-inspection-traffic class, so
you can simply add VXLAN inspection to the inspection_default service policy rule. Alternatively, you can
create a class for it using port or ACL matching.
History for Basic Internet Protocol Inspection

Feature Name Releases Feature Information
DCERPC inspection support for ISystemMapper 9.4(1) The ASA started supporting non-EPM DCERPC messages in
UUID message RemoteGetClassObject opnum3. release 8.3, supporting the ISystemMapper UUID message
RemoteCreateInstance opnum4. This change extends support
to the RemoteGetClassObject opnum3 message.
We did not modify any ASDM screens.
VXLAN packet inspection 9.4(1) The ASA can inspect the VXLAN header to enforce compliance
with the standard format.
> Service Policy Rules > Add Service Policy Rule > Rule
Actions > Protocol Inspection.
IP Options inspection improvements. 9.5(1) IP Options inspection now supports all possible IP options. You
can tune the inspection to allow, clear, or drop any standard or
experimental options, including those not yet defined. You can
also set a default behavior for options not explicitly defined in
an IP options inspection map.
We changed the IP Options Inspect Map dialog box to include
additional options. You now select which options to allow and
optionally clear.
DCERPC inspection improvements and UUID 9.5(2) DCERPC inspection now supports NAT for OxidResolver
filtering ServerAlive2 opnum5 messages. You can also now filter on
DCERPC message universally unique identifiers (UUIDs) to
reset or log particular message types. There is a new DCERPC
inspection class map for UUID filtering.
We added the following screen: Configuration > Firewall >
Objects > Class Maps > DCERPC. We modified the following
screen: Configuration > Firewall > Objects > Inspect
Maps > DCERPC.
329
History for Basic Internet Protocol Inspection
330
CHAPTER 14
Inspection for Voice and Video Protocols
The following topics explain application inspection for voice and video protocols. For basic information on
why you need to use inspection for certain protocols, and the overall methods for applying inspection, see
Getting Started with Application Layer Protocol Inspection, on page 281.
• CTIQBE Inspection, page 331

• H.323 Inspection, page 332
• MGCP Inspection, page 336
• RTSP Inspection, page 338
• SIP Inspection, page 341
• Skinny (SCCP) Inspection, page 345
• History for Voice and Video Protocol Inspection, page 348
CTIQBE Inspection
CTIQBE protocol inspection supports NAT, PAT, and bidirectional NAT. This enables Cisco IP SoftPhone
and other Cisco TAPI/JTAPI applications to work successfully with Cisco CallManager for call setup across
the ASA.
TAPI and JTAPI are used by many Cisco VoIP applications. CTIQBE is used by Cisco TSP to communicate
with Cisco CallManager.
For information on enabling CTIQBE inspection, see Configure Application Layer Protocol Inspection, on
page 288.
Limitations for CTIQBE Inspection

Stateful failover of CTIQBE calls is not supported.
The following summarizes special considerations when using CTIQBE application inspection in specific
scenarios:
• If two Cisco IP SoftPhones are registered with different Cisco CallManagers, which are connected to
different interfaces of the ASA, calls between these two phones fail.
331
H.323 Inspection
• When Cisco CallManager is located on the higher security interface compared to Cisco IP SoftPhones,
if NAT or outside NAT is required for the Cisco CallManager IP address, the mapping must be static
as Cisco IP SoftPhone requires the Cisco CallManager IP address to be specified explicitly in its Cisco
TSP configuration on the PC.
• When using PAT or Outside PAT, if the Cisco CallManager IP address is to be translated, its TCP port
2748 must be statically mapped to the same port of the PAT (interface) address for Cisco IP SoftPhone
registrations to succeed. The CTIQBE listening port (TCP 2748) is fixed and is not user-configurable
on Cisco CallManager, Cisco IP SoftPhone, or Cisco TSP.
H.323 Inspection
H.323 inspection supports RAS, H.225, and H.245, and its functionality translates all embedded IP addresses
and ports. It performs state tracking and filtering and can do a cascade of inspect function activation. H.323
inspection supports phone number filtering, dynamic T.120 control, H.245 tunneling control, HSI groups,
protocol state tracking, H.323 call duration enforcement, and audio/video control.
H.323 inspection is enabled by default. You need to configure it only if you want non-default processing.
The following sections describe the H.323 application inspection.
H.323 Inspection Overview

H.323 inspection provides support for H.323 compliant applications such as Cisco CallManager. H.323 is a
suite of protocols defined by the International Telecommunication Union for multimedia conferences over
LANs. The ASA supports H.323 through Version 6, including H.323 v3 feature Multiple Calls on One Call
Signaling Channel.
With H.323 inspection enabled, the ASA supports multiple calls on the same call signaling channel, a feature
introduced with H.323 Version 3. This feature reduces call setup time and reduces the use of ports on the
ASA.
The two major functions of H.323 inspection are as follows:
• NAT the necessary embedded IPv4 addresses in the H.225 and H.245 messages. Because H.323 messages
are encoded in PER encoding format, the ASA uses an ASN.1 decoder to decode the H.323 messages.
• Dynamically allocate the negotiated H.245 and RTP/RTCP connections. The H.225 connection can also
be dynamically allocated when using RAS.
How H.323 Works

The H.323 collection of protocols collectively may use up to two TCP connection and four to eight UDP
connections. FastConnect uses only one TCP connection, and RAS uses a single UDP connection for
registration, admissions, and status.
An H.323 client can initially establish a TCP connection to an H.323 server using TCP port 1720 to request
Q.931 call setup. As part of the call setup process, the H.323 terminal supplies a port number to the client to
use for an H.245 TCP connection. In environments where H.323 gatekeeper is in use, the initial packet is
transmitted using UDP.
332
H.323 Inspection
H.323 inspection monitors the Q.931 TCP connection to determine the H.245 port number. If the H.323
terminals are not using FastConnect, the ASA dynamically allocates the H.245 connection based on the
inspection of the H.225 messages. The H.225 connection can also be dynamically allocated when using RAS.
Within each H.245 message, the H.323 endpoints exchange port numbers that are used for subsequent UDP
data streams. H.323 inspection inspects the H.245 messages to identify these ports and dynamically creates
connections for the media exchange. RTP uses the negotiated port number, while RTCP uses the next higher
port number.
The H.323 control channel handles H.225 and H.245 and H.323 RAS. H.323 inspection uses the following
ports.
• 1718—Gate Keeper Discovery UDP port
• 1719—RAS UDP port
• 1720—TCP Control Port
You must permit traffic for the well-known H.323 port 1719 for RAS signaling. Additionally, you must permit
traffic for the well-known H.323 port 1720 for the H.225 call signaling; however, the H.245 signaling ports
are negotiated between the endpoints in the H.225 signaling. When an H.323 gatekeeper is used, the ASA
opens an H.225 connection based on inspection of the ACF and RCF messages.
After inspecting the H.225 messages, the ASA opens the H.245 channel and then inspects traffic sent over
the H.245 channel as well. All H.245 messages passing through the ASA undergo H.245 application inspection,
which translates embedded IP addresses and opens the media channels negotiated in H.245 messages.
Each UDP connection with a packet going through H.323 inspection is marked as an H.323 connection and
times out with the H.323 timeout as configured in the Configuration > Firewall > Advanced > Global Timeouts
pane.
Note You can enable call setup between H.323 endpoints when the Gatekeeper is inside the network. The ASA
includes options to open pinholes for calls based on the RegistrationRequest/RegistrationConfirm
(RRQ/RCF) messages. Because these RRQ/RCF messages are sent to and from the Gatekeeper, the calling
endpoint's IP address is unknown and the ASA opens a pinhole through source IP address/port 0/0. By
default, this option is disabled.
H.239 Support in H.245 Messages

The ASA sits between two H.323 endpoints. When the two H.323 endpoints set up a telepresentation session
so that the endpoints can send and receive a data presentation, such as spreadsheet data, the ASA ensure
successful H.239 negotiation between the endpoints.
H.239 is a standard that provides the ability for H.300 series endpoints to open an additional video channel
in a single call. In a call, an endpoint (such as a video phone), sends a channel for video and a channel for
data presentation. The H.239 negotiation occurs on the H.245 channel.
The ASA opens pinholes for the additional media channel and the media control channel. The endpoints use
open logical channel message (OLC) to signal a new channel creation. The message extension is part of H.245
version 13.
The decoding and encoding of the telepresentation session is enabled by default. H.239 encoding and decoding
is preformed by ASN.1 coder.
333
H.323 Inspection
Limitations for H.323 Inspection

H.323 inspection is tested and supported for Cisco Unified Communications Manager (CUCM) 7.0. It is not
supported for CUCM 8.0 and higher. H.323 inspection might work with other releases and products.
The following are some of the known issues and limitations when using H.323 application inspection:
• Only static NAT and dynamic PAT are fully supported. Static PAT may not properly translate IP addresses
embedded in optional fields within H.323 messages. If you experience this kind of problem, do not use
static PAT with H.323.
• Not supported with dynamic NAT.
• Not supported with extended PAT.
• Not supported with NAT between same-security-level interfaces.
• Not supported with NAT64.
Configure H.323 Inspection Policy Map

You can create an H.323 inspection policy map to customize H.323 inspection actions if the default inspection
You can optionally create a H.323 inspection class map to define the traffic class for H.323 inspection. The
other option is to define the traffic classes directly in the H.323 inspection policy map. The difference between
You can configure H.323 class maps by selecting Configuration > Firewall > Objects > Class Maps
> H.323, or by creating them while configuring the inspection map.
Before You Begin

Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > H.323.
334
H.323 Inspection
description only.
Step 4 In the Security Level view of the H.323 Inspect Map dialog box, select the level that best matches your desired
procedure, and use the map in a service policy rule for H.323 inspection.
Tip The Phone Number Filtering button is a shortcut to configure called or calling party inspection, which
is explained later in this procedure.
Step 5 If you need to customize the settings further, click Details, and do the following:
a) Click the State Checking tab and choose whether to enable state transition checking of RAS and H.225
messages.
You can also check RCF messages and open pinholes for call signal addresses present in RRQ messages,
which enables call setup between H.323 endpoints when the Gatekeeper is inside the network. Use this
option to open pinholes for calls based on the RegistrationRequest/RegistrationConfirm (RRQ/RCF)
messages. Because these RRQ/RCF messages are sent to and from the Gatekeeper, the calling endpoint's
IP address is unknown and the ASA opens a pinhole through source IP address/port 0/0. By default, this
option is disabled.
b) Click the Call Attributes tab and choose whether to enforce a call duration limit (maximum is 1193 hours)
or to enforce the presence of calling and called party numbers during call setup.
c) Click the Tunneling and Protocol Conformance tab and choose whether check for H.245 tunneling; you
can either drop the connection or log it.
You can also choose whether to check RTP packets that are flowing on the pinholes for protocol
conformance. If you check for conformance, you can also choose whether to limit the payload to audio
or video, based on the signaling exchange.
Step 6 If necessary, click the HSI Group Parameters tab and define the HSI groups.
• Click Add to add a new group.
• Select an existing group and click Edit.
b) Specify the group ID (from 0 to 2147483647) and the IP address of the HSI.
c) To add an endpoint to the HSI group, enter the IP address, select the interface through which the endpoint
is connected to the ASA, and click Add>>. Remove any endpoints that are no longer needed. You can
have up to 10 endpoints per group.
d) Click OK to add the group. Repeat the process as needed.
characteristics.
You can define traffic matching criteria based on H.323 class maps, by configuring matches directly in the
H.323 class map that defines the criteria.
335
MGCP Inspection
the criterion) or No Match (traffic must not match the criterion). Then, configure the criterion as follows:
• Called Party—Match the H.323 called party against the selected regular expression or regular
expression class.
• Calling Party—Match the H.323 calling party against the selected regular expression or regular
expression class.
• Media Type—Match the media type: audio, video, or data.
d) Choose the action to take for matching traffic. For calling or called party matching, you can drop the
packet, drop the connection, or reset the connection. For media type matching, the action is always to drop
the packet; you can enable logging for this action.
Step 8 Click OK in the H.323 Inspect Map dialog box.
You can now use the inspection map in an H.323 inspection service policy.
What to Do Next
MGCP Inspection
MGCP inspection is not enabled in the default inspection policy, so you must enable it if you need this
inspection. However, the default inspect class does include the default MGCP ports, so you can simply edit
the default global inspection policy to add MGCP inspection. You can alternatively create a new service policy
as desired, for example, an interface-specific policy.
The following sections describe MGCP application inspection.
MGCP Inspection Overview

MGCP is a master/slave protocol used to control media gateways from external call control elements called
media gateway controllers or call agents. A media gateway is typically a network element that provides
conversion between the audio signals carried on telephone circuits and data packets carried over the Internet
or over other packet networks. Using NAT and PAT with MGCP lets you support a large number of devices
on an internal network with a limited set of external (global) addresses. Examples of media gateways are:
• Trunking gateways, that interface between the telephone network and a Voice over IP network. Such
gateways typically manage a large number of digital circuits.
• Residential gateways, that provide a traditional analog (RJ11) interface to a Voice over IP network.
Examples of residential gateways include cable modem/cable set-top boxes, xDSL devices, broad-band
wireless devices.
• Business gateways, that provide a traditional digital PBX interface or an integrated soft PBX interface
to a Voice over IP network.
336
MGCP Inspection
MGCP messages are transmitted over UDP. A response is sent back to the source address (IP address and
UDP port number) of the command, but the response may not arrive from the same address as the command
was sent to. This can happen when multiple call agents are being used in a failover configuration and the call
agent that received the command has passed control to a backup call agent, which then sends the response.
The following figure illustrates how you can use NAT with MGCP.
Figure 49: Using NAT with MGCP
MGCP endpoints are physical or virtual sources and destinations for data. Media gateways contain endpoints
on which the call agent can create, modify and delete connections to establish and control media sessions with
other multimedia endpoints. Also, the call agent can instruct the endpoints to detect certain events and generate
signals. The endpoints automatically communicate changes in service state to the call agent.
• Gateways usually listen to UDP port 2427 to receive commands from the call agent.
• The port on which the call agent receives commands from the gateway. Call agents usually listen to
UDP port 2727 to receive commands from the gateway.
Note MGCP inspection does not support the use of different IP addresses for MGCP signaling and RTP data.
A common and recommended practice is to send RTP data from a resilient IP address, such as a loopback
or virtual IP address; however, the ASA requires the RTP data to come from the same address as MGCP
signaling.
Configure an MGCP Inspection Policy Map

If the network has multiple call agents and gateways for which the ASA has to open pinholes, create an MGCP
map. You can then apply the MGCP map when you enable MGCP inspection.
337
RTSP Inspection
Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > MGCP.
description only.
Step 4 (Optional) Click the Command Queue tab and specify the maximum number of commands allowed in the
MGCP command queue. The default is 200, the allowed range is 1 to 2147483647.
Step 5 Click the Gateways and Call Agents tab and configure the groups of gateways and call agents for the map.
a) Click Add to create a new group, or select a group and click Edit.
b) Enter the Group ID of the call agent group. A call agent group associates one or more call agents with
one or more MGCP media gateways. The valid range is from 0 to 2147483647.
c) Add the IP addresses of the media gateways that are controlled by the associated call agents to the group
by entering them in Gateway to Be Added and clicking Add>>. Delete any gateways that are no longer
used.
A media gateway is typically a network element that provides conversion between the audio signals carried
on telephone circuits and data packets carried over the Internet or over other packet networks. Normally,
a gateway sends commands to the default MGCP port for call agents, UDP 2727.
d) Add the IP addresses of the call agents that control the MGCP media gateways by entering them in Call
Agent to Be Added and clicking Add>>. Delete any agents that are no longer needed.
Normally, a call agent sends commands to the default MGCP port for gateways, UDP 2427.
e) Click OK in the MGCP Group dialog box. Repeat the process to add other groups as needed.
Step 6 Click OK in the MGCP Inspect Map dialog box.
You can now use the inspection map in an MGCP inspection service policy.
What to Do Next
RTSP Inspection
RTSP inspection is enabled by default. You need to configure it only if you want non-default processing. The
following sections describe RTSP application inspection.
RTSP Inspection Overview

The RTSP inspection engine lets the ASA pass RTSP packets. RTSP is used by RealAudio, RealNetworks,
Apple QuickTime 4, RealPlayer, and Cisco IP/TV connections.
338
RTSP Inspection
Note For Cisco IP/TV, use RTSP TCP ports 554 and 8554.
RTSP applications use the well-known port 554 with TCP (rarely UDP) as a control channel. The ASA only
supports TCP, in conformity with RFC 2326. This TCP control channel is used to negotiate the data channels
that are used to transmit audio/video traffic, depending on the transport mode that is configured on the client.
The supported RDT transports are: rtp/avp, rtp/avp/udp, x-real-rdt, x-real-rdt/udp, and x-pn-tng/udp.
The ASA parses Setup response messages with a status code of 200. If the response message is traveling
inbound, the server is outside relative to the ASA and dynamic channels need to be opened for connections
coming inbound from the server. If the response message is outbound, then the ASA does not need to open
dynamic channels.
RTSP inspection does not support PAT or dual-NAT. Also, the ASA cannot recognize HTTP cloaking where
RTSP messages are hidden in the HTTP messages.
RealPlayer Configuration Requirements

When using RealPlayer, it is important to properly configure transport mode. For the ASA, add an access-list
command from the server to the client or vice versa. For RealPlayer, change transport mode by clicking
Options>Preferences>Transport>RTSP Settings.
If using TCP mode on the RealPlayer, select the Use TCP to Connect to Server and Attempt to use TCP
for all content check boxes. On the ASA, there is no need to configure the inspection engine.
If using UDP mode on the RealPlayer, select the Use TCP to Connect to Server and Attempt to use UDP
for static content check boxes, and for live content not available via multicast. On the ASA, add an inspect
rtsp command.
Limitations for RSTP Inspection

The following restrictions apply to the RSTP inspection.
• The ASA does not support multicast RTSP or RTSP messages over UDP.
• The ASA does not have the ability to recognize HTTP cloaking where RTSP messages are hidden in
the HTTP messages.
• The ASA cannot perform NAT on RTSP messages because the embedded IP addresses are contained
in the SDP files as part of HTTP or RTSP messages. Packets could be fragmented and the ASA cannot
perform NAT on fragmented packets.
• With Cisco IP/TV, the number of translates the ASA performs on the SDP part of the message is
proportional to the number of program listings in the Content Manager (each program listing can have
at least six embedded IP addresses).
• You can configure NAT for Apple QuickTime 4 or RealPlayer. Cisco IP/TV only works with NAT if
the Viewer and Content Manager are on the outside network and the server is on the inside network.
339
RTSP Inspection
Configure RTSP Inspection Policy Map

You can create an RTSP inspection policy map to customize RTSP inspection actions if the default inspection
You can optionally create a RTSP inspection class map to define the traffic class for RTSP inspection. The
other option is to define the traffic classes directly in the RTSP inspection policy map. The difference between
You can configure RTSP class maps by selecting Configuration > Firewall > Objects > Class Maps >
RTSP, or by creating them while configuring the inspection map.
Before You Begin

Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > RTSP.
• Select a map to and click Edit.
description only.
Step 4 Click the Parameters tab and configure the desired options:
• Enforce Reserve Port Protection—Whether to restrict the use of reserved ports during media port
negotiation.
• Maximum URL Length—The maximum length of the URL allowed in the message, 0 to 6000.
characteristics.
You can define traffic matching criteria based on RTSP class maps, by configuring matches directly in the
340
SIP Inspection
RTSP class map that defines the criteria.
• URL Filter—Match the URL against the selected regular expression or regular expression class.
• Request Method—Match the request method: announce, describe, get_parameter, options, pause,
play, record, redirect, setup, set_parameters, teardown.
d) Choose the action to take for matching traffic. For URL matching, you can drop the connection or log it,
and you can enable logging of dropped connections. For Request Method matches, you can apply a rate
limit in packets per second.
Step 6 Click OK in the RTSP Inspect Map dialog box.
You can now use the inspection map in an RTSP inspection service policy.
What to Do Next
SIP Inspection
SIP is a widely used protocol for Internet conferencing, telephony, presence, events notification, and instant
messaging. Partially because of its text-based nature and partially because of its flexibility, SIP networks are
subject to a large number of security threats.
SIP application inspection provides address translation in message header and body, dynamic opening of ports
and basic sanity checks. It also supports application security and protocol conformance, which enforce the
sanity of the SIP messages, as well as detect SIP-based attacks.
SIP inspection is enabled by default. You need to configure it only if you want non-default processing, or if
you want to identify a TLS proxy to enable encrypted traffic inspection. The following topics explain SIP
inspection in more detail.
SIP Inspection Overview

SIP, as defined by the IETF, enables call handling sessions, particularly two-party audio conferences, or
“calls.” SIP works with SDP for call signaling. SDP specifies the ports for the media stream. Using SIP, the
ASA can support any SIP VoIP gateways and VoIP proxy servers. SIP and SDP are defined in the following
RFCs:
• SIP: Session Initiation Protocol, RFC 3261
• SDP: Session Description Protocol, RFC 2327
341
SIP Inspection
To support SIP calls through the ASA, signaling messages for the media connection addresses, media ports,
and embryonic connections for the media must be inspected, because while the signaling is sent over a
well-known destination port (UDP/TCP 5060), the media streams are dynamically allocated. Also, SIP embeds
IP addresses in the user-data portion of the IP packet. Note that the maximum length of the SIP Request URI
that the ASA supports is 255.
Instant Messaging (IM) applications also use SIP extensions (defined in RFC 3428) and SIP-specific event
notifications (RFC 3265). After users initiate a chat session (registration/subscription), the IM applications
use the MESSAGE/INFO methods and 202 Accept responses when users chat with each other. For example,
two users can be online at any time, but not chat for hours. Therefore, the SIP inspection engine opens pinholes
that time out according to the configured SIP timeout value. This value must be configured at least five minutes
longer than the subscription duration. The subscription duration is defined in the Contact Expires value and
is typically 30 minutes.
Because MESSAGE/INFO requests are typically sent using a dynamically allocated port other than port 5060,
they are required to go through the SIP inspection engine.
Note SIP inspection supports the Chat feature only. Whiteboard, File Transfer, and Application Sharing are not
supported. RTC Client 5.0 is not supported.
Limitations for SIP Inspection

SIP inspection is tested and supported for Cisco Unified Communications Manager (CUCM) 7.0, 8.0, 8.6,
and 10.5. It is not supported for CUCM 8.5, or 9.x. SIP inspection might work with other releases and products.
SIP inspection applies NAT for embedded IP addresses. However, if you configure NAT to translate both
source and destination addresses, the external address (“from” in the SIP header for the “trying” response
message) is not rewritten. Thus, you should use object NAT when working with SIP traffic so that you avoid
translating the destination address.
The following limitations and restrictions apply when using PAT with SIP:
• If a remote endpoint tries to register with a SIP proxy on a network protected by the ASA, the registration
fails under very specific conditions, as follows:
◦PAT is configured for the remote endpoint.
◦The SIP registrar server is on the outside network.
◦The port is missing in the contact field in the REGISTER message sent by the endpoint to the
proxy server.
• If a SIP device transmits a packet in which the SDP portion has an IP address in the owner/creator field
(o=) that is different than the IP address in the connection field (c=), the IP address in the o= field may
not be properly translated. This is due to a limitation in the SIP protocol, which does not provide a port
value in the o= field.
• When using PAT, any SIP header field which contains an internal IP address without a port might not
be translated and hence the internal IP address will be leaked outside. If you want to avoid this leakage,
configure NAT instead of PAT.
342
SIP Inspection
Default SIP Inspection

SIP inspection is enabled by default using the default inspection map, which includes the following:
• SIP instant messaging (IM) extensions: Enabled.
• Non-SIP traffic on SIP port: Permitted.
• Hide server’s and endpoint’s IP addresses: Disabled.
• Mask software version and non-SIP URIs: Disabled.
• Ensure that the number of hops to destination is greater than 0: Enabled.
• RTP conformance: Not enforced.
• SIP conformance: Do not perform state checking and header validation.
Also note that inspection of encrypted traffic is not enabled. You must configure a TLS proxy to inspect
encrypted traffic.
Configure SIP Inspection Policy Map

You can create a SIP inspection policy map to customize SIP inspection actions if the default inspection
You can optionally create a SIP inspection class map to define the traffic class for SIP inspection. The other
option is to define the traffic classes directly in the SIP inspection policy map. The difference between creating
match criteria and you can reuse class maps. Although this procedure explains inspection maps, the matching
criteria used in class maps are the same as those explained in the step relating to the Inspection tab. You can
configure SIP class maps by selecting Configuration > Firewall > Objects > Class Maps > SIP, or by
creating them while configuring the inspection map.
Before You Begin

Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > SIP.
343
SIP Inspection
description only.
Step 4 In the Security Level view of the SIP Inspect Map dialog box, select the level that best matches your desired
procedure, and use the map in a service policy rule for SIP inspection.
a) Click the Filtering tab and choose whether to enable SIP instant messaging (IM) extensions or to permit
non-SIP traffic on the SIP port.
b) Click the IP Address Privacy tab and choose whether to hide the server and endpoint IP addresses.
c) Click the Hop Count tab and choose whether to ensure that the number of hops to the destination is greater
than 0. This checks the value of the Max-Forwards header, which cannot be zero before reaching the
destination. You must also choose the action to take for non-conforming traffic (drop packet, drop
connection, reset, or log) and whether to enable or disable logging.
d) Click the RTP Conformance tab and choose whether to check RTP packets that are flowing on the
pinholes for protocol conformance. If you check for conformance, you can also choose whether to limit
the payload to audio or video, based on the signaling exchange.
e) Click the SIP Conformance tab and choose whether to enable state transition checking and strict validation
of header fields. For each option you choose, select the action to take for non-conforming traffic (drop
packet, drop connection, reset, or log) and whether to enable or disable logging.
f) Click the Field Masking tab and choose whether to inspect non-SIP URIs in Alert-Info and Call-Info
headers and to inspect the server’s and endpoint’s software version in the User-Agent and Server headers.
For each option you choose, select the action to take (mask or log) and whether to enable or disable logging.
g) Click the TVS Server tab and identify the Trust Verification Services servers, which enable Cisco Unified
IP Phones to authenticate application servers during HTTPS establishment. You can identify up to four
servers; enter their IP addresses separated by commas. SIP inspection opens pinholes to each server for
each registered phone, and the phone decides which to use.
Configure the Trust Verification Services server on the CUCM server. If the configuration uses a non-default
port, enter the port number (in the range 1026 to 32768). The default port is 2445.
characteristics.
You can define traffic matching criteria based on SIP class maps, by configuring matches directly in the
SIP class map that defines the criteria.
• Called Party—Match the called party, as specified in the To header, against the selected regular
344
Skinny (SCCP) Inspection
• Calling Party—Match the calling party, as specified in the From header, against the selected regular
• Content Length—Match a SIP content header of a length greater than specified, between 0 and
65536 bytes.
• Content Type—Match the Content Type header, either the SDP type or a type that matches the
selected regular expression or regular expression class.
• IM Subscriber—Match the SIP IM subscriber against the selected regular expression or regular
expression class.
• Message Path—Match the SIP Via header against the selected regular expression or regular expression
class.
• Request Method—Match the SIP request method: ack, bye, cancel, info, invite, message, notify,
options, prack, refer, register, subscribe, unknown, update.
• Third-Party Registration—Match the requester of a third-party registration against the selected
regular expression or regular expression class.
• URI Length—Match a URI in the SIP headers of the selected type (SIP or TEL) that is greater than
the length specified, between 0 and 65536 bytes.
d) Choose the action to take for matching traffic (drop packet, drop connection, reset, log) and whether to
enable or disable logging. For Request Method matches to “invite” and “register,” you can also apply a
rate limit in packets per second.
Step 7 Click OK in the SIP Inspect Map dialog box.
You can now use the inspection map in a SIP inspection service policy.
What to Do Next

SCCP (Skinny) application inspection performs translation of embedded IP address and port numbers within
the packet data, and dynamic opening of pinholes. It also performs additional protocol conformance checks
and basic state tracking.
SCCP inspection is enabled by default. You need to configure it only if you want non-default processing, or
if you want to identify a TLS proxy to enable encrypted traffic inspection.
The following sections describe SCCP application inspection.
345
SCCP Inspection Overview

Skinny (SCCP) is a simplified protocol used in VoIP networks. Cisco IP Phones using SCCP can coexist in
an H.323 environment. When used with Cisco CallManager, the SCCP client can interoperate with H.323
compliant terminals.
The ASA supports PAT and NAT for SCCP. PAT is necessary if you have more IP phones than global IP
addresses for the IP phones to use. By supporting NAT and PAT of SCCP Signaling packets, Skinny application
inspection ensures that all SCCP signaling and media packets can traverse the ASA.
Normal traffic between Cisco CallManager and Cisco IP Phones uses SCCP and is handled by SCCP inspection
without any special configuration. The ASA also supports DHCP options 150 and 66, which it accomplishes
by sending the location of a TFTP server to Cisco IP Phones and other DHCP clients. Cisco IP Phones might
also include DHCP option 3 in their requests, which sets the default route.
Note The ASA supports inspection of traffic from Cisco IP Phones running SCCP protocol version 22 and
earlier.
Supporting Cisco IP Phones

In topologies where Cisco CallManager is located on the higher security interface with respect to the Cisco
IP Phones, if NAT is required for the Cisco CallManager IP address, the mapping must be static as a Cisco
IP Phone requires the Cisco CallManager IP address to be specified explicitly in its configuration. A static
identity entry allows the Cisco CallManager on the higher security interface to accept registrations from the
Cisco IP Phones.
Cisco IP Phones require access to a TFTP server to download the configuration information they need to
connect to the Cisco CallManager server.
When the Cisco IP Phones are on a lower security interface compared to the TFTP server, you must use an
ACL to connect to the protected TFTP server on UDP port 69. While you do need a static entry for the TFTP
server, this does not have to be an identity static entry. When using NAT, an identity static entry maps to the
same IP address. When using PAT, it maps to the same IP address and port.
When the Cisco IP Phones are on a higher security interface compared to the TFTP server and
Cisco CallManager, no ACL or static entry is required to allow the Cisco IP Phones to initiate the connection.
Limitations for SCCP Inspection

SCCP inspection is tested and supported for Cisco Unified Communications Manager (CUCM) 7.0, 8.0, 8.6,
and 10.5. It is not supported for CUCM 8.5, or 9.x. SCCP inspection might work with other releases and
products.
If the address of an internal Cisco CallManager is configured for NAT or PAT to a different IP address or
port, registrations for external Cisco IP Phones fail because the ASA does not support NAT or PAT for the
file content transferred over TFTP. Although the ASA supports NAT of TFTP messages and opens a pinhole
for the TFTP file, the ASA cannot translate the Cisco CallManager IP address and port embedded in the Cisco
IP Phone configuration files that are transferred by TFTP during phone registration.
346
Note The ASA supports stateful failover of SCCP calls except for calls that are in the middle of call setup.
Default SCCP Inspection

SCCP inspection is enabled by default using these defaults:
• Registration: Not enforced.
• Maximum message ID: 0x181.
• Minimum prefix length: 4
• Media timeout: 00:05:00
• Signaling timeout: 01:00:00.
• RTP conformance: Not enforced.
Also note that inspection of encrypted traffic is not enabled. You must configure a TLS proxy to inspect
encrypted traffic.
Configure a Skinny (SCCP) Inspection Policy Map

To specify actions when a message violates a parameter, create an SCCP inspection policy map. You can then
apply the inspection policy map when you enable SCCP inspection.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > SCCP (Skinny).
description only.
Step 4 In the Security Level view of the SCCP (Skinny) Inspect Map dialog box, select the level that best matches
your desired configuration. The default level is Low.
procedure, and use the map in a service policy rule for SCCP inspection.
a) Click the Parameters tab and choose among the following options:
• Enforce endpoint registration—Whether Skinny endpoints must register before placing or receiving
calls.
347
History for Voice and Video Protocol Inspection
• Maximum Message ID—The maximum SCCP station message ID allowed. The default maximum
is 0x181. The hex number can be 0x0 to 0xffff.
• SCCP Prefix Length—The maximum and minimum SCCP prefix length. The default minimum is
4; there is no default maximum.
• Timeouts—Whether to set timeouts for media and signaling connections, and the value of those
timeouts. The defaults are 5 minutes for media, 1 hour for signaling.
b) Click the RTP Conformance tab and choose whether to check RTP packets that are flowing on the
pinholes for protocol conformance. If you check for conformance, you can also choose whether to limit
the payload to audio or video, based on the signaling exchange.
Step 6 (Optional) Click the Message ID Filtering tab to identify traffic to drop based on the station message ID field
in SCCP messages.
not match the criterion).
c) In the Value fields, identify the traffic based on the station message ID value in hexadecimal, from 0x0
to 0xffff. Either enter the value for a single message ID, or enter the beginning and ending value for a
range of IDs.
d) Choose whether to enable or disable logging. The action is always to drop the packet.
e) Click OK to add the filter. Repeat the process as needed.
Step 7 Click OK in the SCCP (Skinny) Inspect Map dialog box.
You can now use the inspection map in an SCCP inspection service policy.
What to Do Next

SIP, SCCP, and TLS Proxy support for IPv6 9.3(1) You can now inspect IPv6 traffic when using SIP, SCCP, and
TLS Proxy (using SIP or SCCP).
348

SIP support for Trust Verification Services, 9.3(2) You can now configure Trust Verification Services servers in
NAT66, CUCM 10.5, and model 8831 phones. SIP inspection. You can also use NAT66. SIP inspection has
been tested with CUCM 10.5.
We added Trust Verification Services Server support to the SIP
inspection policy map.
Improved SIP inspection performance on multiple 9.4(1) If you have multiple SIP signaling flows going through an ASA
core ASA. with multiple cores, SIP inspection performance has been
improved. However, you will not see improved performance if
you are using a TLS, phone, or IME proxy.
SIP inspection support in ASA clustering 9.4(1) You can now configure SIP inspection on the ASA cluster. A
control flow can be created on any unit (due to load balancing),
but its child data flows must reside on the same unit. TLS Proxy
configuration is not supported.
We did not modify any screens.
SIP inspection support for Phone Proxy and 9.4(1) You can no longer use Phone Proxy or UC-IME Proxy when
UC-IME Proxy was removed. configuring SIP inspection. Use TLS Proxy to inspect encrypted
traffic.
We removed Phone Proxy and UC-IME Proxy from the Select
SIP Inspect Map service policy dialog box.
349
350
CHAPTER 15
Inspection for Mobile Networks
The following topics explain application inspection for protocols used in mobile networks such as LTE.
These inspections require the Carrier license. For information on why you need to use inspection for certain
protocols, and the overall methods for applying inspection, see Getting Started with Application Layer
Protocol Inspection, on page 281.
• Mobile Network Inspection Overview, page 351

• Licensing for Mobile Network Protocol Inspection, page 356
• Defaults for GTP Inspection, page 356
• Configure Mobile Network Inspection, page 357
• Monitoring Mobile Network Inspection, page 366
• History for Mobile Network Inspection, page 369
Mobile Network Inspection Overview

The following topics explain the inspections available for protocols used in mobile networks such as LTE.
There are other services available for SCTP traffic in addition to inspection.
GTP Inspection Overview

GPRS Tunneling Protocol is used in GSM, UMTS and LTE networks for general packet radio service (GPRS)
traffic. GTP provides a tunnel control and management protocol to provide GPRS network access for a mobile
station by creating, modifying, and deleting tunnels. GTP also uses a tunneling mechanism for carrying user
data packets.
Service provider networks use GTP to tunnel multi-protocol packets through the GPRS backbone between
endpoints. In GTPv0-1, GTP is used for signaling between gateway GPRS support nodes (GGSN) and serving
GPRS support nodes (SGSN). In GTPv2, the signaling is between Packet Data Network Gateways (PGW)
and the Serving Gateway (SGW) as well as other endpoints. The GGSN/PGW is the interface between the
GPRS wireless data network and other networks. The SGSN/SGW performs mobility, data session management,
and data compression.
351
You can use the ASA to provide protection against rogue roaming partners. Place the device between the
home GGSN/PGW and visited SGSN/SGW endpoints and use GTP inspection on the traffic. GTP inspection
works only on traffic between these endpoints. In GTPv2, this is known as the S5/S8 interface.
GTP and associated standards are defined by 3GPP (3rd Generation Partnership Project). For detailed
information, see http://www.3gpp.org.
Following are some limitations on GTP inspection:
• GTPv2 piggybacking messages are not supported. They are always dropped.
• GTPv2 emergency UE attach is supported only if it contains IMSI (International Mobile Subscriber
Identity).
• GTP inspection does not inspect early data. That is, data sent from a PGW or SGW right after a Create
Session Request but before the Create Session Response.
• For GTPv2, inspection supports up to 3GPP 29.274 Release 10 version 13. For GTPv0/v1, support is
up to release 9 of 3GPP 29.060.
• GTP inspection does not support inter-SGSN handoff to the secondary PDP context. Inspection needs
to do the handoff for both primary and secondary PDP contexts.
Stream Control Transmission Protocol (SCTP) Inspection and Access Control

SCTP (Stream Control Transmission Protocol) is described in RFC 4960. The protocol supports the telephony
signaling protocol SS7 over IP and is also a transport protocol for several interfaces in the 4G LTE mobile
network architecture.
SCTP is a transport-layer protocol operating on top of IP in the protocol stack, similar to TCP and UDP.
However, SCTP creates a logical communication channel, called an association, between two end nodes over
one or more source or destination IP addresses. This is called multi-homing. An association defines a set of
IP addresses on each node (source and destination) and a port on each node. Any IP address in the set can be
used as either a source or a destination IP address of data packets associated to this association to form multiple
connections. Within each connection, multiple streams may exist to send messages. A stream in SCTP represents
a logical application data channel.
352
The following figure illustrates the relationship between an association and its streams.
Figure 50: Relationship Between SCTP Association and Streams
If you have SCTP traffic going through the ASA, you can control access based on SCTP ports, and implement
application layer inspection to enable connections and to optionally filter on payload protocol ID to selectively
drop, log, or rate limit applications.
The following sections describe the services available for SCTP traffic in more detail.
SCTP Stateful Inspection

Similar to TCP, SCTP traffic is automatically inspected at layer 4 to ensure well-structured traffic and limited
RFC 4960 enforcement. The following protocol elements are inspected and enforced:
• Chunk types, flags, and length.
• Verification tags.
• Source and destination ports, to prevent association redirect attacks.
• IP addresses.
SCTP stateful inspection accepts or rejects packets based on the association state:
• Validating the 4-way open and close sequences for initial association establishment.
• Verifying the forward progression of TSN within an association and a stream.
• Terminating an association when seeing the ABORT chunk due to heartbeat failure. SCTP endpoints
might send the ABORT chunk in response to bombing attacks.
If you decide you do not want these enforcement checks, you can configure SCTP state bypass for specific
traffic classes, as explained in Configure Connection Settings for Specific Traffic Classes (All Services), on
page 387.
Note SCTP stateful inspection and state bypass are not available in a cluster.
353
SCTP Access Control

You can create access rules for SCTP traffic. These rules are similar to TCP/UDP port-based rules, where
you simply use sctp as the protocol, and the port numbers are SCTP ports. You can create service objects or
groups for SCTP, or specify the ports directly. See the following topics.
• Configure Service Objects and Service Groups, on page 31
• Configure Extended ACLs, on page 42
• Configure Access Rules, on page 17
SCTP NAT
You can apply static network object NAT to the addresses in SCTP association establishment messages.
Although you can configure static twice NAT, this is not recommended because the topology of the destination
part of the SCTP association is unknown. You cannot use dynamic NAT/PAT.
NAT for SCTP depends upon SCTP stateful inspection rather than SCTP application-layer inspection. Thus,
you cannot NAT traffic if you configure SCTP state bypass. You also cannot NAT SCTP traffic in a cluster.
SCTP Application Layer Inspection

You can further refine your access rules by enabling SCTP inspection and filtering on SCTP applications.
You can selectively drop, log, or rate limit SCTP traffic classes based on the payload protocol identifier
(PPID).
If you decide to filter on PPID, keep the following in mind:
• PPIDs are in data chunks, and a given packet can have multiple data chunks or even a control chunk. If
a packet includes a control chunk or multiple data chunks, the packet will not be dropped even if the
assigned action is drop.
• If you use PPID filtering to drop or rate-limit packets, be aware that the transmitter will resend any
dropped packets. Although a packet for a rate-limited PPID might make it through on the next attempt,
a packet for a dropped PPID will again be dropped. You might want to evaluate the eventual consequence
of these repeated drops on your network.
Diameter Inspection
Diameter is an Authentication, Authorization, and Accounting (AAA) protocol used in next-generation mobile
and fixed telecom networks such as EPS (Evolved Packet System) for LTE (Long Term Evolution) and IMS
(IP Multimedia Subsystem). It replaces RADIUS and TACACS in these networks.
Diameter uses TCP and SCTP as the transport layer, and secures communications using TCP/TLS and
SCTP/DTLS. It can optionally provide data object encryption as well. For detailed information on Diameter,
see RFC 6733.
Diameter applications perform service management tasks such as deciding user access, service authorization,
quality of service, and rate of charging. Although Diameter applications can appear on many different
control-plane interfaces in the LTE architecture, the ASA inspects Diameter command codes and attribute-value
pairs (AVP) for the following interfaces only:
• S6a: Mobility Management Entity (MME) - Home Subscription Service (HSS).
354
• S9: PDN Gateway (PDG) - 3GPP AAA Proxy/Server.

• Rx: Policy Charging Rules Function (PCRF) - Call Session Control Function (CSCF).
Diameter inspection opens pinholes for Diameter endpoints to allow communication. The inspection supports
3GPP version 12 and is RFC 6733 compliant.
You can optionally use a Diameter inspection policy map to filter traffic based on application ID, command
codes, and AVP, to apply special actions such as dropping packets or connections, or logging them. You can
create custom AVP for newly-registered Diameter applications. Filtering lets you fine-tune the traffic you
allow on your network.
Note Diameter messages for applications that run on other interfaces will be allowed and passed through by
default. However, you can configure a Diameter inspection policy map to drop these applications by
application ID, although you cannot specify actions based on the command codes or AVP for these
unsupported applications.
RADIUS Accounting Inspection Overview

The purpose of RADIUS accounting inspection is to prevent over-billing attacks on GPRS networks that use
RADIUS servers. Although you do not need the Carrier license to implement RADIUS accounting inspection,
it has no purpose unless you are implementing GTP inspection and you have a GPRS setup.
The over-billing attack in GPRS networks results in consumers being billed for services that they have not
used. In this case, a malicious attacker sets up a connection to a server and obtains an IP address from the
SGSN. When the attacker ends the call, the malicious server will still send packets to it, which gets dropped
by the GGSN, but the connection from the server remains active. The IP address assigned to the malicious
attacker gets released and reassigned to a legitimate user who will then get billed for services that the attacker
will use.
RADIUS accounting inspection prevents this type of attack by ensuring the traffic seen by the GGSN is
legitimate. With the RADIUS accounting feature properly configured, the ASA tears down a connection based
on matching the Framed IP attribute in the Radius Accounting Request Start message with the Radius
Accounting Request Stop message. When the Stop message is seen with the matching IP address in the Framed
IP attribute, the ASA looks for all connections with the source matching the IP address.
You have the option to configure a secret pre-shared key with the RADIUS server so the ASA can validate
the message. If the shared secret is not configured, the ASA will only check that the source IP address is one
of the configured addresses allowed to send the RADIUS messages.
Note When using RADIUS accounting inspection with GPRS enabled, the ASA checks for the
3GPP-Session-Stop-Indicator in the Accounting Request STOP messages to properly handle secondary
PDP contexts. Specifically, the ASA requires that the Accounting Request STOP messages include the
3GPP-SGSN-Address attribute before it will terminate the user sessions and all associated connections.
Some third-party GGSNs might not send this attribute by default.
355
Licensing for Mobile Network Protocol Inspection
Licensing for Mobile Network Protocol Inspection

Inspection of the following protocols requires the license listed in the table below.
• GTP
• SCTP. You also need this license to use SCTP protocol specifications in ACLs and access rules.
• Diameter
Model License Requirement

Carrier license
• ASA 5525-X
• ASA 5545-X
• ASA 5555-X
• ASA 5585-X
• ASASM
ASAv (all models) Carrier license (enabled by default)
ASA on the Firepower 9300 Carrier license
All other models The Carrier license is not available on other models. You cannot inspect these protocols.
Defaults for GTP Inspection

GTP inspection is not enabled by default. However, if you enable it without specifying your own inspection
map, a default map is used which provides the following processing. You need to configure a map only if you
want different values.
• Errors are not permitted.
• The maximum number of requests is 200.
• The maximum number of tunnels is 500. This is equivalent to the number of PDP contexts (endpoints).
• The GTP endpoint timeout is 30 minutes. Endpoints include GSNs (GTPv0,1) and SGW/PGW (GTPv2).
• The PDP context timeout is 30 minutes. In GTPv2, this is the bearer context timeout.
• The request timeout is 1 minute.
• The signaling timeout is 30 minutes.
• The tunneling timeout is 1 hour.
• The T3 response timeout is 20 seconds.
356
Configure Mobile Network Inspection
• Unknown message IDs are dropped and logged. This behavior is confined to messages the 3GPP defines
for the S5S8 interface. Messages defined for other GPRS interfaces might be allowed with minimal
inspection.

Inspections for protocols used in mobile networks are not enabled by default. You must configure them if
you want to support mobile networks.
Procedure
Step 1 (Optional.) Configure a GTP Inspection Policy Map, on page 357.

Step 2 (Optional.) Configure an SCTP Inspection Policy Map, on page 359.
Step 3 (Optional.) Configure a Diameter Inspection Policy Map, on page 361.
If you want to filter on attribute-value pairs (AVP) that are not yet supported in the software, you can create
custom AVP for use in the Diameter inspection policy map. See Create a Custom Diameter Attribute-Value
Pair (AVP), on page 363.
Step 4 Configure the Mobile Network Inspection Service Policy , on page 364.
Step 5 (Optional.) Configure RADIUS Accounting Inspection, on page 365.
RADIUS accounting inspection protects against over-billing attacks.
Configure a GTP Inspection Policy Map

If you want to enforce additional parameters on GTP traffic, and the default map does not meet your needs,
create and configure a GTP map.
Before You Begin

Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > GTP.
• Select a map to view its contents. Click Customize to edit the map. The remainder of the procedure
assumes you are customizing or adding a map.
description only.
Step 4 In the Security Level view of the GTP Inspect Map dialog box, view the current configuration of the map.
357
The view indicates whether the map uses default values or if you have customized it. If you need to customize
the settings further, click Details, and continue with the procedure.
Tip The IMSI Prefix Filtering button is a shortcut to configure IMSI prefix filtering, which is explained
later in this procedure.
Step 5 Click the Permit Parameters tab and configure the desired options.
• Permit Response—When the ASA performs GTP inspection, by default the ASA drops GTP responses
from GSNs or PGWs that were not specified in the GTP request. This situation occurs when you use
load-balancing among a pool of GSN/PGW endpoints to provide efficiency and scalability of GPRS.
To configure GSN/PGW pooling and thus support load balancing, create a network object group that
specifies the GSN/PGW endpoints and select this as a “From Object Group.” Likewise, create a network
object group for the SGSN/SGW and select it as the “To Object Group.” If the GSN/PGW responding
belongs to the same object group as the GSN/PGW that the GTP request was sent to and if the SGSN/SGW
is in an object group that the responding GSN/PGW is permitted to send a GTP response to, the ASA
permits the response.
The network object group can identify the endpoints by host address or by the subnet that contains them.
• Permit Errors—Whether to allow packets that are invalid or that encountered an error during inspection
to be sent through the ASA instead of being dropped.
Step 6 Click the General Parameters tab and configure the desired options:
• Maximum Number of Requests—The maximum number of GTP requests that will be queued waiting
for a response.
• Maximum Number of Tunnels—The maximum number of active GTP tunnels allowed. This is
equivalent to the number of PDP contexts or endpoints. The default is 500. New requests will be dropped
once the maximum number of tunnels is reached.
• Enforce Timeout—Whether to enforce idle timeouts for the following behaviors. Timeouts are in
hh:mm:ss format.
◦Endpoint—The maximum period of inactivity before a GTP endpoint is removed.
◦PDP-Context—The maximum period of inactivity before removing the PDP Context for a GTP
session. In GTPv2, this is the bearer context.
◦Request—The maximum period of inactivity after which a request is removed from the request
queue. Any subsequent responses to a dropped request will also be dropped.
◦Signaling—The maximum period of inactivity before GTP signaling is removed.
◦T3-Response timeout—The maximum wait time for a response before removing the connection.
◦Tunnel—The maximum period of inactivity for the GTP tunnel before it is torn down.
Step 7 Click the IMSI Prefix Filtering tab and configure IMSI prefix filtering if desired.
By default, the security appliance does not check for valid Mobile Country Code (MCC)/Mobile Network
Code (MNC) combinations. If you configure IMSI prefix filtering, the MCC and MNC in the IMSI of the
received packet is compared with the configured MCC/MNC combinations and is dropped if it does not match.
The Mobile Country Code is a non-zero, three-digit value; add zeros as a prefix for one- or two-digit values.
The Mobile Network Code is a two- or three-digit value.
358
Add all permitted MCC and MNC combinations. By default, the ASA does not check the validity of MNC
and MCC combinations, so you must verify the validity of the combinations configured. To find more
information about MCC and MNC codes, see the ITU E.212 recommendation, Identification Plan for Land
Mobile Stations.
characteristics.
not match the criterion). Then, configure the criterion:
• Access Point Name—Matches the access point name against the specified regular expression or
regular expression class. By default, all messages with valid access point names are inspected and
any name is allowed.
• Message ID—Matches the message ID, from 1 to 255. You can specify one value or a range of
values. You must specify whether the message is for GTPv1 (which includes GTPv0) or GTPv2. By
default, all valid message IDs are allowed.
• Message Length—Matches messages where the length of the UDP payload is between the specified
minimum and maximum length.
• Version—Matches the GTP version, from 0 to 255. You can specify one value or a range of values.
By default all GTP versions are allowed.
c) For Message ID matching, choose whether to drop the packet or to apply a rate limit in packets per second.
The action for all other matches is to drop the packet. For all matches, you can choose whether to enable
logging.
Step 9 Click OK in the GTP Inspect Map dialog box.
You can now use the inspection map in a GTP inspection service policy.
What to Do Next
You can now configure an inspection policy to use the map. See Configure the Mobile Network Inspection
Service Policy , on page 364.
Configure an SCTP Inspection Policy Map

To apply alternative actions to SCTP traffic based on the application-specific payload protocol identifier
(PPID), such as rate limiting, create an SCTP inspection policy map to be used by the service policy.
359
Note PPIDs are in data chunks, and a given packet can have multiple data chunks or even a control chunk. If a
packet includes a control chunk or multiple data chunks, the packet will not be dropped even if the assigned
action is drop. For example, if you configure an SCTP inspection policy map to drop PPID 26, and a PPID
26 data chunk is combined in a packet with a Diameter PPID data chunk, that packet will not be dropped.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > SCTP.
description only.
Step 4 Drop, rate limit, or log traffic based on the PPID in SCTP data chunks.
b) Choose the match type for the criteria: Match (traffic must match the PPID) or No Match (traffic must
not match the PPID).
For example, if you select No Match is on the Diameter PPID, then all PPIDs except Diameter are excluded
from the class map.
c) Choose the Minimum Payload PID and optionally, the Maximum Payload PID to match.
You can enter PPIDs by name or number (0-4294967295). Click the ... button in each field to select from
a list of PPIDs. If you select a maximum PPID, then the match applies to the range of PPIDs
You can find the current list of SCTP PPIDs at http://www.iana.org/assignments/sctp-parameters/
sctp-parameters.xhtml#sctp-parameters-25.
d) Choose whether to drop (and log), log, or rate limit (in kilobits per second, kbps) the matching packets.
Step 5 Click OK in the SCTP Inspect Map dialog box.
You can now use the inspection map in an SCTP inspection service policy.
What to Do Next
360
Configure a Diameter Inspection Policy Map

You can create a Diameter inspection policy map to filter on various Diameter protocol elements. You can
then selectively drop or log connections.
To configure Diameter message filtering, you must have a good knowledge of these protocol elements as they
are defined in RFCs and technical specifications. For example, the IETF has a list of registered applications,
command codes, and attribute-value pairs at http://www.iana.org/assignments/aaa-parameters/
aaa-parameters.xhtml, although Diameter inspection does not support all listed items. See the 3GPP web site
for their technical specifications.
You can optionally create a Diameter inspection class map to define the message filtering criteria for Diameter
inspection. The other option is to define the filtering criteria directly in the Diameter inspection policy map.
The difference between creating a class map and defining the filtering criteria directly in the inspection map
is that you can create more complex match criteria and you can reuse class maps. Although this procedure
explains inspection maps, the matching criteria used in class maps are the same as those explained in the step
relating to the Inspection tab. You can configure Diameter class maps by selecting Configuration > Firewall
> Objects > Class Maps > Diameter, or by creating them while configuring the inspection map.
Before You Begin

Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > Diameter.
• Select a map and click Edit. to view its contents.
description only.
Step 4 Click the Unsupported Parameters tab and choose whether you want to log messages that include unsupported
Diameter elements.
You can log application IDs, command codes, and attribute-value pairs (AVP) that are not directly supported
by the software. The default is to allow the elements without logging them.
characteristics.
You can define traffic matching criteria based on Diameter class maps, by configuring matches directly in
the inspection map, or both.
361
Diameter class map that defines the criteria.
the criterion) or No Match (traffic must not match the criterion). Then, configure the criterion as follows:
• Application ID—Enter the Diameter application name or number (0-4294967295). If there is a
range of consecutively-numbered applications that you want to match, you can include a second ID.
You can define the range by application name or number, and it applies to all the numbers between
the first and second IDs.
These applications are registered with the IANA. Following are the core supported applications, but
you can filter on other applications.
◦3gpp-rx-ts29214 (16777236)
◦3gpp-s6a (16777251)
◦3gpp-s9 (16777267)
◦common-message (0). This is the base Diameter protocol.
• Command Code—Enter the Diameter command code name or number (0-4294967295). If there is
a range of consecutively-numbered command codes that you want to match, you can include a second
code. You can define the range by command code name or number, and it applies to all the numbers
between the first and second codes.
For example, to match the Capability Exchange Request/Answer command code, CER/CEA, enter
cer-cea.
• Attribute Value Pair—You can match the AVP by attribute only, a range of AVPs, or an AVP
based on the value of the attribute. For the AVP Begin Value, you can specify the name of a custom
AVP or one that is registered in RFCs or 3GPP technical specifications and is directly supported in
the software. Click the ... button in the field to pick from a list.
If you want to match a range of AVP, specify the AVP End Value by number only. If you want to
match an AVP by its value, you cannot specify a second code.
You can further refine the match by specifying the optional Vendor ID, from 0-4294967295. For
example, the 3GPP vendor ID is 10415, the IETF is 0.
You can configure value-matching only if the data type of the AVP is supported. For example, you
can specify an IP address for AVP that have the address data type. The list of AVP shows the data
type for each. How you specify the value differs based on the AVP data type:
◦Diameter Identity, Diameter URI, Octet String—Select the regular expression or regular
expression class objects to match these data types.
◦Address—Specify the IPv4 or IPv6 address to match. For example, 10.100.10.10 or
2001:DB8::0DB8:800:200C:417A.
◦Time—Specify the start and end dates and time. Both are required. Time is in 24-hour format.
◦Numeric—Specify a range of numbers. The valid number range depends on the data type:
◦Integer32: -2147483647 to 2147483647
◦Integer64: -9223372036854775807 to 9223372036854775807
362
◦Unsigned32: 0 to 4294967295
◦Unsigned64: 0 to 18446744073709551615
◦Float32: decimal point representation with 8 digit precision
◦Float64: decimal point representation with 16 digit precision
d) Choose the action to take for matching traffic: drop packet, drop connection, or log.
Step 6 Click OK in the Diameter Inspect Map dialog box.
You can now use the inspection map in a Diameter inspection service policy.
What to Do Next
Create a Custom Diameter Attribute-Value Pair (AVP)

As new attribute-value pairs (AVP) are defined and registered, you can create custom Diameter AVP to define
them and use them in your Diameter inspection policy map. You would get the information you need to create
the AVP from the RFC or other source that defines the AVP.
Create custom AVP only if you want to use them in a Diameter inspection policy map or class map for AVP
matching.
Procedure
Step 1 Select Configuration > Firewall > Objects > Inspect Maps > Diameter AVP.
Step 2 Click Add to create a new AVP.
When you edit an AVP, you can change the description only.
Step 3 Configure the following options:

• Name—The name of the custom AVP you are creating, up to 32 characters. You would refer to this
name in a Diameter inspection policy map or class map when defining an attribute-value pair match.
• Custom Code—The custom AVP code value, from 256-4294967295. You cannot enter a code and
vendor ID combination that is already defined in the system.
• Data Type—The data type of the AVP. You can define AVP of the following types. If the new AVP
is of a different type, you cannot create a custom AVP for it.
◦Address (for IP addresses)
◦Diameter identity
◦Diameter uniform resource identifier (URI)
◦32-bit floating point number
363
◦64-bit floating point number

◦32-bit integer
◦64-bit integer
◦Octet string
◦Time
◦32-bit unsigned integer
◦64-bit unsigned integer
• Vendor ID—(Optional.) The ID number of the vendor who defined the AVP, from 0-4294967295. For
example, the 3GPP vendor ID is 10415, the IETF is 0.
• Description—(Optional.) A description of the AVP, up to 80 characters.
Step 4 Click OK.
Configure the Mobile Network Inspection Service Policy

Inspections for the protocols used in mobile networks are not enabled in the default inspection policy, so you
must enable them if you need these inspections. You can simply edit the default global inspection policy to
add these inspections. You can alternatively create a new service policy as desired, for example, an
interface-specific policy.
Procedure
• To edit the default global policy, select the “inspection_default” rule in the Global folder and click Edit.
page.
• If you have a mobile network inspection rule, or a rule to which you are adding these inspections, select
it and click Edit.
Step 2 On the Rule Actions wizard page or tab, select the Protocol Inspection tab.
must disable the inspections, and then re-enable them with the new inspection policy map name:
a) Uncheck the relevant already-selected check boxes: GTP, SCTP, and Diameter.
b) Click OK.
c) Click Apply.
Step 4 Select the desired mobile network protocols: GTP, SCTP, and Diameter .
Step 5 If you want non-default inspection for one or more of these protocols, click Configure next to the options,
and do the following:
364
a) Choose whether to use the default map or to use a GTP/SCTP/Diameter inspection policy map that you
configured. You can create the map at this time.
b) Click OK in the Select Inspect Map dialog box.
Step 6 Click OK or Finish to save the service policy rule.
Configure RADIUS Accounting Inspection

RADIUS accounting inspection is not enabled by default. You must configure it if you want RADIUS
accounting inspection.
Procedure
Step 1 Configure a RADIUS Accounting Inspection Policy Map, on page 365.

Step 2 Configure the RADIUS Accounting Inspection Service Policy, on page 366.
Configure a RADIUS Accounting Inspection Policy Map

You must create a RADIUS accounting inspection policy map to configure the attributes needed for the
inspection.
Procedure
Step 1 Choose Configuration > Firewall > Objects > Inspect Maps > RADIUS Accounting.
description only.
Step 4 Click the Host Parameters tab and add the IP addresses of each RADIUS server or GGSN.
You can optionally include a secret key so that the ASA can validate the message. Without the key, only the
IP address is checked. The ASA receives a copy of the RADIUS accounting messages from these hosts.
Step 5 Click the Other Parameters tab and configure the desired options.
• Send responses to the originator of the RADIUS accounting message—xxWhether to mask the
banner from the ESMTP server.
• Enforce user timeout—Whether to implement an idle timeout for users, and the timeout value. The
default is one hour.
• Enable detection of GPRS accounting—Whether to implement GPRS over-billing protection. The
ASA checks for the 3GPP VSA 26-10415 attribute in the Accounting-Request Stop and Disconnect
messages in order to properly handle secondary PDP contexts. If this attribute is present, then the ASA
tears down all connections that have a source IP matching the User IP address on the configured interface.
365
Monitoring Mobile Network Inspection
• Validate Attribute—Additional criteria to use when building a table of user accounts when receiving
Accounting-Request Start messages. These attributes help when the ASA decides whether to tear down
connections.
If you do not specify additional attributes to validate, the decision is based solely on the IP address in
the Framed IP Address attribute. If you configure additional attributes, and the ASA receives a start
accounting message that includes an address that is currently being tracked, but the other attributes to
validate are different, then all connections started using the old attributes are torn down, on the assumption
that the IP address has been reassigned to a new user.
Values range from 1-191, and you can enter the command multiple times. For a list of attribute numbers
and their descriptions, see http://www.iana.org/assignments/radius-types.
Step 6 Click OK.

You can now use the inspection map in a RADIUS accounting inspection service policy.
Configure the RADIUS Accounting Inspection Service Policy

RADIUS accounting inspection is not enabled in the default inspection policy, so you must enable it if you
need this inspection. Because RADIUS accounting inspection is for traffic directed to the ASA, you must
configure it as a management inspection rule rather than a standard rule.
Procedure
• To create a new rule, click Add > Add Management Service Policy Rule. Proceed through the wizard
to the Rules page.
• If you have a RADIUS accounting inspection rule, or a management rule to which you are adding
RADIUS accounting inspection, select it, click Edit, and click the Rule Actions tab.
must disable the RADIUS accounting inspection, and then re-enable it with the new inspection policy map
name:
a) Select None for the RADIUS Accounting map.
b) Click OK.
c) Click Apply.
Step 3 Choose the desired RADIUS Accounting Map. You can create the map at this time. For detailed information,
see Configure a RADIUS Accounting Inspection Policy Map, on page 365.
Step 4 Click OK or Finish to save the management service policy rule.

The following topics explain how to monitor mobile network inspection.
366
Monitoring GTP Inspection

To display the GTP configuration, enter the show service-policy inspect gtp command in privileged EXEC
mode. Select Tools > Command Line Interface to enter commands.
Use the show service-policy inspect gtp statistics command to show the statistics for GTP inspection. The
following is sample output:
firewall(config)# show service-policy inspect gtp statistics

GPRS GTP Statistics:
version_not_support 0 msg_too_short 0
unknown_msg 0 unexpected_sig_msg 0
unexpected_data_msg 0 ie_duplicated 0
mandatory_ie_missing 0 mandatory_ie_incorrect 0
optional_ie_incorrect 0 ie_unknown 0
ie_out_of_order 0 ie_unexpected 0
total_forwarded 67 total_dropped 1
signalling_msg_dropped 1 data_msg_dropped 0
signalling_msg_forwarded 67 data_msg_forwarded 0
total created_pdp 33 total deleted_pdp 32
total created_pdpmcb 31 total deleted_pdpmcb 30
total dup_sig_mcbinfo 0 total dup_data_mcbinfo 0
no_new_sgw_sig_mcbinfo 0 no_new_sgw_data_mcbinfo 0
pdp_non_existent 1
You can get statistics for a specific GTP endpoint by entering the IP address on the show service-policy
inspect gtp statistics ip_address command.
firewall(config)# show service-policy inspect gtp statistics 10.9.9.9

1 in use, 1 most used, timeout 0:30:00
GTP GSN Statistics for 10.9.9.9, Idle 0:00:34, restart counter 0
Tunnels Active 0
Tunnels Created 1
Tunnels Destroyed 0
Total Messages Received 1
Signalling Messages Data Messages
total received 1 0
dropped 0 0
forwarded 1 0
Use the show service-policy inspect gtp pdp-context command to display PDP context-related information.
For GTPv2, this is the bearer context. For example:
ciscoasa(config)# show service-policy inspect gtp pdp-context

1 in use, 32 most used
Version TID MS Addr SGSN Addr Idle Timeout APN

v2 2692026893437055 10.0.0.1 10.0.0.11 0:00:11 0:04:00 gprs.example.com
ciscoasa(config)# show service-policy inspect gtp pdp-context detail

1 in use, 32 most used
Version TID MS Addr SGSN Addr Idle Timeout APN

v2 2692026893437055 10.0.0.1 10.0.0.11 0:00:13 0:04:00 gprs.example.com
user_name (IMSI): 622920863934075 MS address: 10.0.0.1

ebi: 5 lebi: 0
primary pdp: Y
sgw_addr_signal: 10.0.0.11 sgw_addr_data: 10.0.0.11
pgw_addr_signal: 10.1.0.21 pgw_addr_data: 10.1.0.21
sgw control teid: 0x50010001 sgw data teid: 0x60010001
pgw control teid: 0x70010001 pgw data teid: 0x80010001
signal_sequence: 0 state: Ready
367
The PDP or bearer context is identified by the tunnel ID (TID), which is a combination of the values for IMSI
and NSAPI (GTPv0-1) or IMSI and EBI (GTPv2). A GTP tunnel is defined by two associated contexts in
different GSN or SGW/PGW nodes and is identified with a Tunnel ID. A GTP tunnel is necessary to forward
packets between an external packet data network and a mobile subscriber (MS) user.
Monitoring SCTP
You can use the following commands to monitor SCTP. Select Tools > Command Line Interface to enter
these commands.
• show service-policy inspect sctp
Displays SCTP inspection statistics. The sctp-drop-override counter increments each time a PPID is
matched to a drop action, but the packet was not dropped because it contained data chunks with different
PPIDs. For example:
ciscoasa# show service-policy inspect sctp

Global policy:
Inspect: sctp sctp, packet 153302, lock fail 0, drop 20665, reset-drop 0,
5-min-pkt-rate 0 pkts/sec, v6-fail-close 0, sctp-drop-override 4910
Match ppid 30 35
rate-limit 1000 kbps, chunk 2354, dropped 10, bytes 21408, dropped-bytes
958
Match: ppid 40
drop, chunk 5849
Match: ppid 55
log, chunk 9546
• show sctp
Displays current SCTP cookies and associations. For example:
ciscoasa# show sctp
AssocID: 2279da7a
Local: 192.168.107.11/20001 (ESTABLISHED)
Remote: 192.168.108.11/40174 (ESTABLISHED)
AssocID: 4924f520
Local: 192.168.107.11/20001 (ESTABLISHED)
Remote: 192.168.108.11/40200 (ESTABLISHED)
• show conn protocol sctp

Displays information about current SCTP connections.
• show local-host [connection sctp start[-end]]
Displays information on hosts making SCTP connections through the ASA, per interface. Add the
connection sctp keyword to see only those hosts with the specified number or range of SCTP connections.
• show traffic
Displays SCTP connection and inspection statistics per interface if you enable the sysopt traffic
detailed-statistics command.
368
History for Mobile Network Inspection
Monitoring Diameter
You can use the following commands to monitor Diameter. Select Tools > Command Line Interface to
enter these commands.
• show service-policy inspect diameter
Displays Diameter inspection statistics. For example:
ciscoasa# show service-policy inspect diameter

Global policy:
Inspect: Diameter Diameter_map, packet 0, lock fail 0, drop 0, -drop 0,
5-min-pkt-rate 0 pkts/sec, v6-fail-close 0
Class-map: log_app
Log: 5849
Class-map: block_ip
drop-connection: 2
• show diameter
Displays state information for each Diameter connection. For example:
ciscoasa# show diameter

Total active diameter sessions: 5
Session 3638
==========
ref_count: 1 val = .; 1096298391; 2461;
Protocol : diameter Context id : 0
From inside:211.1.1.10/45169 to outside:212.1.1.10/3868
...
• show conn detail

Displays connection information. Diameter connections are marked with the Q flag.

GTPv2 inspection and improvements to GTPv0/1 9.5(1) GTP inspection can now handle GTPv2. In addition, GTP
inspection. inspection for all versions now supports IPv6 addresses.
We changed the GTP Inspect Map > Inspections dialog box
to let you configure separate message ID matching for GTPv1
and GTPv2. On the General parameters tab, the GSN timeout
is now the Endpoint timeout.
SCTP inspection 9.5(2) You can now apply application-layer inspection to Stream
Control Transmission Protocol (SCTP) traffic to apply actions
based on payload protocol identifier (PPID).
We added or changed the following screens: Configuration
> Firewall > Objects > Inspect Maps > SCTP;
Configuration > Firewall > Service Policy add/edit wizard's
Rule Actions > Protocol Inspection tab.
369

Diameter inspection 9.5(2) You can now apply application-layer inspection to Diameter
traffic and also apply actions based on application ID, command
code, and attribute-value pair (AVP) filtering.
We added or changed the following screens: Configuration
> Firewall > Objects > Inspect Maps > Diameter and
Diameter AVP; Configuration > Firewall > Service Policy
add/edit wizard's Rule Actions > Protocol Inspection tab.
370
PART IV
Connection Management and Threat Detection
• Connection Settings, page 373
• Quality of Service, page 393
• Threat Detection, page 403
CHAPTER 16
Connection Settings
This chapter describes how to configure connection settings for connections that go through the ASA, or for
management connections that go to the ASA.
• What Are Connection Settings?, page 373

• Configure Connection Settings, page 374
• Monitoring Connections, page 389
• History for Connection Settings, page 390
What Are Connection Settings?

Connection settings comprise a variety of features related to managing traffic connections, such as a TCP
flow through the ASA. 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.
• 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 ASA. You can set limits on particular traffic classes 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
373
Configure Connection Settings
the connection is valid. The show service-policy command includes counters to show the amount of
activity from DCD.
• TCP sequence randomization—Each TCP connection has two ISNs: one generated by the client and
one generated by the server. By default, the ASA 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.
• TCP State Bypass—You can bypass TCP state checking if you use asymmetrical routing in your
network.
• SCTP State Bypass—You can bypass Stream Control Transmission Protocol (SCTP) stateful inspection
if you do not want SCTP protocol validation.
• Flow offloading—You can identify select traffic to be offloaded to a super fast path, where the flows
are switched in the NIC itself. Offloading can help you improve performance for data-intensive
applications such as large file transfers.

Connection limits, timeouts, TCP Normalization, TCP sequence randomization, and decrementing time-to-live
(TTL) have default values that are appropriate for most networks. You need to configure these connection
settings only if you have unusual requirements, your network has specific types of configuration, or if you
are experiencing unusual connection loss due to premature idle timeouts.
Other connection-related features are not enabled. You would configure these services on specific traffic
classes only, and not as a general service. These features include the following: TCP Intercept, TCP State
Bypass, Dead Connection Detection (DCD), SCTP state bypass, flow offload.
The following general procedure covers the gamut of possible connection setting configurations. Pick and
choose which to implement based on your needs.
374
Procedure
Step 1 Configure Global Timeouts, on page 375. These settings change the default idle timeouts for various protocols
for all traffic that passes through the device. If you are having problems with connections being reset due to
premature timeouts, first try changing the global timeouts.
Step 2 Protect Servers from a SYN Flood DoS Attack (TCP Intercept), on page 377. Use this procedure to configure
TCP Intercept.
Step 3 Customize Abnormal TCP Packet Handling (TCP Maps, TCP Normalizer), on page 379, if you want to alter
the default TCP Normalization behavior for specific traffic classes.
Step 4 Bypass TCP State Checks for Asynchronous Routing (TCP State Bypass), on page 381, if you have this type
of routing environment.
Step 5 Disable TCP Sequence Randomization, on page 383, if the default randomization is scrambling data for certain
connections.
Step 6 Offload Large Flows, on page 384, if you need to improve performance in a computing intensive data center.
Step 7 Configure Connection Settings for Specific Traffic Classes (All Services), on page 387. This is a catch-all
procedure for connection settings. These settings can override the global defaults for specific traffic classes
using service policy rules. You also use these rules to customize TCP Normalizer, change TCP sequence
randomization, decrement time-to-live on packets, and implement other optional features.
Configure Global Timeouts

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.
Changing the global timeout sets a new default timeout, which in some cases can be overridden for particular
traffic flows through service policies.
Procedure
Step 1 Choose Configuration > Firewall > Advanced > Global Timeouts.
Step 2 Configure the timeouts by checking the boxes for timeouts you want to change and entering the new value.
All durations are displayed in the format hh:mm:ss, with a maximum duration of 1193:0:0 in most cases. In
all cases, except for Authentication absolute and Authentication inactivity, unchecking the check boxes returns
the timeout to the default value. For those two cases, clearing the check box means to reauthenticate on every
new connection.
Enter 0 to disable a timeout.
• Connection—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.
375
• ICMP—The idle time after which general ICMP states are closed. The default (and minimum) is 2
seconds.
• 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.
• 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.
• MGCP—The idle time after which an MGCP media connection is removed. The default is 5 minutes,
but you can set it as low as 1 second.
• MGCP PAT—The idle time after which an MGCP PAT translation is removed. The default is 5 minutes.
The minimum time is 30 seconds.
• 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).
• 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.
• SCTP—The idle time until a Stream Control Transmission Protocol (SCTP) connection closes, between
0:1:0 and 1193:0:0. The default is 2 minutes (0:2:0).
• SUNRPC—The idle time until a SunRPC slot is freed. This duration must be at least 1 minute. The
default is 10 minutes.
• 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 Provisional Media—The timeout value for SIP provisional media connections, between 1 and 30
minutes. The default is 2 minutes.
• 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 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).
• Authentication absolute—The duration until the authentication cache times out and users have to
reauthenticate a new connection. This timer is used in cut-through proxy only, which is a AAA rule.
This duration must be shorter than the Translation Slot timeout. The system waits until the user starts a
new connection to prompt again. Before you disable caching to force authentication on every new
connection, consider the following limitations.
◦Do not set this value to 0 if passive FTP is used on the connections.
◦When Authentication Absolute is 0, HTTPS authentication may not work. If a browser initiates
multiple TCP connections to load a web page after HTTPS authentication, the first connection is
376
permitted through, but subsequent connections trigger authentication. As a result, users are
continuously presented with an authentication page, even after successful authentication. To work
around this, set the authentication absolute timeout to 1 second. This workaround opens a 1-second
window of opportunity that might allow non-authenticated users to go through the firewall if they
are coming from the same source IP address.
• Authentication inactivity—The idle time until the authentication cache times out and users have to
reauthenticate a new connection. This duration must be shorter than the Translation Slot value. This
timeout is disabled by default. This timer is used in cut-through proxy only, which is a AAA rule.
• Translation Slot—The idle time until a NAT translation slot is freed. This duration must be at least 1
minute. The default is 3 hours.
• (8.4(3) and later, not including 8.5(1) and 8.6(1)) PAT Translation Slot—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.
Step 3 Click Apply.
Protect Servers from a SYN Flood DoS Attack (TCP Intercept)

A SYN-flooding denial of service (DoS) attack occurs when an attacker sends a series of SYN packets to a
host. These packets usually originate from spoofed IP addresses. The constant flood of SYN packets keeps
the server SYN queue full, which prevents it from servicing connection requests from legitimate users.
You can limit the number of embryonic connections to help prevent SYN flooding attacks. An embryonic
connection is a connection request that has not finished the necessary handshake between source and destination.
When the embryonic connection threshold of a connection is crossed, the ASA 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 ASA 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.
Note 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.
The end-to-end process for protecting a server from a SYN flood attack involves setting connection limits,
enabling TCP Intercept statistics, and then monitoring the results.
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.
377
• Depending on the number of CPU cores on your ASA 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 ASA 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.
Procedure
Step 1 Choose Configuration > Firewall > Service Policy.

Step 2 Click Add > Add Service Policy Rule.
Alternatively, if you already have a rule for the servers you want to protect, edit the rule.
Step 3 Select whether to apply the rule to a specific interface or globally to all interfaces, and click Next.
Step 4 For Traffic Classification, select Source and Destination IP Addresses (uses ACL) and click Next.
Step 5 For the ACL rule, enter the IP addresses of the servers in Destination, and specify the protocol for the servers.
Typically, you would use any for the Source. Click Next when finished.
For example, if you want to protect the web servers 10.1.1.5 and 10.1.1.6, enter:
• Source = any
• Destination = 10.1.1.5, 10.1.1.6
• Destination Protocol = tcp/http
Step 6 On the Rule Actions page, click the Connection Settings tab and fill in these options:
• Embryonic Connections—The maximum number of embryonic connections per host up to 2000000.
The default is 0, which means the maximum embryonic connections are allowed. For example, you
could set this to 1000.
• Per Client Embryonic Connections—The maximum number of simultaneous TCP embryonic
connections for each client up to 2000000. When a new TCP connection is requested by a client that
already has the maximum per-client number of embryonic connections open through the ASA, the ASA
prevents the connection. For example, you could set this to 50.
Step 7 Click Finish to save the rule, and Apply to update the device.
Step 8 Choose Configuration > Firewall > Threat Detection, and enable at least the TCP Intercept statistics
under the Threat Detection Statistics group.
You can simply enable all statistics, or just enable TCP Intercept. You can also adjust the monitoring window
and rates.
Step 9 Choose Home > Firewall Dashboard, and look at the Top Ten Protected Servers under SYN Attack
dashboard to monitor the results.
Click the Detail button to show history sampling data. The ASA samples the number of attacks 30 times
during the rate interval, so for the default 30 minute period, statistics are collected every 60 seconds.
You can clear the statistics by entering the clear threat-detection statistics tcp-intercept command using
Tools > Command Line Interface.
378
Customize Abnormal TCP Packet Handling (TCP Maps, TCP Normalizer)

The TCP Normalizer identifies abnormal packets that the ASA can act on when they are detected; for example,
the ASA can allow, drop, or clear the packets. TCP normalization helps protect the ASA from attacks. TCP
normalization is always enabled, but you can customize how some features behave.
To customize the TCP normalizer, first define the settings using a TCP map. Then, you can apply the map to
selected traffic classes using service policies.
Procedure
Step 1 Choose Configuration > Firewall > Objects > TCP Maps.
• Click Add to add a new TCP map. Enter a name for the map.
Step 3 In the Queue Limit field, enter the maximum number of out-of-order packets that can be buffered and put in
order for a TCP connection, between 0 and 250 packets.
The default is 0, which means this setting is disabled and the default system queue limit is used depending
on the type of traffic:
• Connections for application inspection, IPS, and TCP check-retransmission have a queue limit of 3
packets. If the ASA receives a TCP packet with a different window size, then the queue limit is
dynamically changed to match the advertised setting.
• For other TCP connections, out-of-order packets are passed through untouched.
If you set the Queue Limit to be 1 or above, then the number of out-of-order packets allowed for all TCP
traffic matches this setting. For example, for application inspection, IPS, and TCP check-retransmission traffic,
any advertised settings from TCP packets are ignored in favor of the Queue Limit setting. For other TCP
traffic, out-of-order packets are now buffered and put in order instead of passed through untouched.
Step 4 In the Timeout field, set the maximum amount of time that out-of-order packets can remain in the buffer,
between 1 and 20 seconds.
If they are not put in order and passed on within the timeout period, then they are dropped. The default is 4
seconds. You cannot change the timeout for any traffic if the Queue Limit is set to 0; you need to set the limit
to be 1 or above for the Timeout to take effect.
Step 5 For Reserved Bits, select how to handle packets that have reserved bits in the TCP header: Clear and allow
(remove the bits before allowing the packet), Allow only (do not change the bits, the default), or Drop the
packet.
Step 6 Select any of the following options:
• Clear urgent flag—Clears the URG flag in a packet before allowing it. The URG flag is used to indicate
that the packet contains information that is of higher priority than other data within the stream. The TCP
RFC is vague about the exact interpretation of the URG flag, therefore end systems handle urgent offsets
in different ways, which may make the end system vulnerable to attacks.
• Drop connection on window variation—Drops a connection that has changed its window size
unexpectedly. The window size mechanism allows TCP to advertise a large window and to subsequently
379
advertise a much smaller window without having accepted too much data. From the TCP specification,
“shrinking the window” is strongly discouraged.
• Drop packets that exceed maximum segment size—Drops packets that exceed the MSS set by the
peer.
• Check if transmitted data is the same as original—Enables the retransmit data checks, which prevent
inconsistent TCP retransmissions.
• Drop packets which have past-window sequence—Drops packets that have past-window sequence
numbers, namely the sequence number of a received TCP packet is greater than the right edge of the
TCP receiving window. To allow these packets, deselect this option and set the Queue Limit to 0
(disabling the queue limit).
• Drop SYN Packets with data—Drops SYN packets that contain data.
• Enable TTL Evasion Protection—Have the maximum TTL for a connection be determined by the
TTL in the initial packet. The TTL for subsequent packets can decrease, but it cannot increase. The
system will reset the TTL to the lowest previously-seen TTL for that connection. This protects against
TTL evasion attacks.
For example, an attacker can send a packet that passes policy with a very short TTL. When the TTL
goes to zero, a router between the ASA and the endpoint drops the packet. It is at this point that the
attacker can send a malicious packet with a long TTL that appears to the ASA to be a retransmission
and is passed. To the endpoint host, however, it is the first packet that has been received by the attacker.
In this case, an attacker is able to succeed without security preventing the attack.
• Verify TCP Checksum—Verifies the TCP checksum, dropping packets that fail verification.
• Drop SYNACK Packets with data—Drops TCP SYNACK packets that contain data.
• Drop packets with invalid ACK—Drops packets with an invalid ACK. You might see invalid ACKs
in the following instances:
◦In the TCP connection SYN-ACK-received status, if the ACK number of a received TCP packet
is not exactly same as the sequence number of the next TCP packet sending out, it is an invalid
ACK.
◦Whenever the ACK number of a received TCP packet is greater than the sequence number of the
next TCP packet sending out, it is an invalid ACK.
Note TCP packets with an invalid ACK are automatically allowed for WAAS connections.
Step 7 Set the action for packets that contain TCP options. You can clear the options before allowing the packets, or
allow the packets without change. The default is to allow the three named options, while clearing all other
options.
• Clear Selective Ack—Clears the selective acknowledgment mechanism option.
• Clear TCP Timestamp—Clears the TCP timestamp. Clearing the timestamp option disables PAWS
and RTT.
• Clear Window Scale—Clears the window scale mechanism option.
• Range—Sets the action for unnamed options. The ranges can be within 6-7 and 9-255. Choose Allow
or Delete (that is, clear) for each range.
380
Step 8 Click OK and Apply.

You can now use the TCP map in a service policy. The map affects traffic only when applied through a service
policy.
Step 9 Apply the TCP map to a traffic class using a service policy.
a) Choose Configuration > Firewall > Service Policy Rules.
b) Add or edit a rule. You can apply the rule globally or to an interface. For example, to customize abnormal
packet handling for all traffic, create a global rule that matches any traffic. Proceed to the Rule Actions
page.
c) Click the Connection Settings tab.
d) Choose Use TCP Map and select the map you created.
e) Click Finish or OK, then click Apply.
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 ASA 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 ASA is inspected using the Adaptive Security Algorithm and is
either allowed through or dropped based on the security policy. The ASA maximizes the firewall performance
by checking the state of each packet (is this a new connection or an 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). See the general operations configuration guide
for more detailed information about the stateful firewall.
TCP packets that match existing connections in the fast path can pass through the ASA 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 ASA.
For example, a new connection goes to ASA 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 ASA 1, then the packets will match the entry in the fast path, and are passed through. But if subsequent
packets go to ASA 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
381
an asymmetric routing example where the outbound traffic goes through a different ASA than the inbound
traffic:
Figure 51: Asymmetric Routing
If you have asymmetric routing configured on upstream routers, and traffic alternates between two ASAs,
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 ASA, and there is
not an 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 for TCP State Bypass
TCP State Bypass Unsupported Features

The following features are not supported when you use TCP state bypass:
• Application inspection—Application inspection requires both inbound and outbound traffic to go through
the same ASA, so application inspection is not applied to TCP state bypass traffic.
• AAA authenticated sessions—When a user authenticates with one ASA, traffic returning via the other
ASA will be denied because the user did not authenticate with that ASA.
• TCP Intercept, maximum embryonic connection limit, TCP sequence number randomization—The ASA
does not keep track of the state of the connection, so these features are not applied.
• TCP normalization—The TCP normalizer is disabled.
• Service module functionality—You cannot use TCP state bypass and any application running on any
type of service module, such as ASA FirePOWER.
• Stateful failover.
382
TCP State Bypass NAT Guidelines

Because the translation session is established separately for each ASA, be sure to configure static NAT on
both ASAs for TCP state bypass traffic. If you use dynamic NAT, the address chosen for the session on ASA
1 will differ from the address chosen for the session on ASA 2.
Configure TCP State Bypass

To bypass TCP state checking in asynchronous routing environments, carefully define a traffic class that
applies to the affected hosts or networks only, then enable TCP State Bypass on the traffic class using a service
policy. Because bypass reduces the security of the network, limit its application as much as possible.
Procedure

Alternatively, if you already have a rule for the hosts, edit the rule.
Step 4 For Traffic Classification, select Source and Destination IP Addresses (uses ACL) and click Next.
Step 5 For the ACL rule, enter the IP addresses of the hosts on each end of the route in Source and Destination, and
specify the protocol as TCP. Click Next when finished.
For example, if you want to bypass TCP state checking between 10.1.1.1 and 10.2.2.2, enter:
• Source = 10.1.1.1
• Destination = 10.2.2.2
• Destination Protocol = tcp
Step 6 On the Rule Actions page, click the Connection Settings tab and select TCP State Bypass.
Disable TCP Sequence Randomization

Each TCP connection has two ISNs: one generated by the client and one generated by the server. The ASA
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. For example:
• 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 ASA, and the eBGP peers are using MD5. Randomization breaks
the MD5 checksum.
• You use a WAAS device that requires the ASA not to randomize the sequence numbers of connections.
383
• 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

Alternatively, if you already have a rule for the targeted traffic, edit the rule.
Step 4 For Traffic Classification, identity the type of traffic match. The class match should be for TCP traffic; you
can identify specific hosts (with an ACL) do a TCP port match, or simply match any traffic. Click Next and
configure the hosts in the ACL or define the ports, and click Next again.
For example, if you want to disable TCP sequence number randomization for all TCP traffic directed at
10.2.2.2, enter:
• Source = any
• Destination = 10.2.2.2
Step 5 On the Rule Actions page, click the Connection Settings tab and uncheck Randomize Sequence Number.
Offload Large Flows

If you deploy the ASA on the FXOS chassis (FXOS 1.1.3 or later) in a data center, you can identify select
traffic to be offloaded to a super fast path, where traffic is switched in the NIC itself. Offloading can help you
improve performance for data-intensive applications such as large file transfers.
• High Performance Computing (HPC) Research sites, where the ASA is deployed between storage and
high compute stations. When one research site backs up using FTP file transfer or file sync over NFS,
all contexts on the ASA are affected by the large amount of data traffic. Offloading FTP file transfer
and file sync over NFS reduces the impact on other traffic.
• High Frequency Trading (HFT), where the ASA is deployed between workstations and the Exchange,
mainly for compliance purposes. Security is usually not a concern, but latency is a major concern.
Before being offloaded, the ASA first applies normal security processing, such as access rules and inspection,
during connection establishment. The ASA also does session tear-down. But once a connection is established,
if it is eligible to be offloaded, further processing happens in the NIC rather than the ASA.
While offloaded, the flow does not receive stateful security checking or other services, so that it can move
through the system as fast as possible. For offloaded flows, there is no inspection, TCP normalization (except
for checksum verification, if you configure it), QoS, or sequence number checking.
To identify flows that can be offloaded, you create a service policy rule that applies the flow offloading service.
A matching flow is then offloaded if it meets the following conditions:
• IPv4 addresses only.
384
• TCP, UDP, GRE only.

• Standard or 802.1q tagged Ethernet frames only.
Reverse flows for offloaded flows are also offloaded.
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:
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.
• Flows that require inspection. In some cases, such as FTP, the secondary data channel can be
offloaded although the control channel cannot be offloaded.
• Flows that pass through another module, such as ASA Firepower.
• IPsec and VPN connections.
• 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.
Conditions for reversing offload

After a flow is offloaded, packets within the flow are returned to the ASA for further processing if they
meet the following conditions:
• They include TCP options other than Timestamp.
• They are fragmented.
385
Configure Flow Offload

To configure flow offload, you must enable the service and then create service policies to identify the traffic
that is eligible for offloading. Enabling or disabling the service requires a reboot. However, adding or editing
service policies does not require a reboot.
Flow offloading is available on the ASA on the FXOS chassis (FXOS 1.1.3 or later) only.
Note For more information on device support, see http://www.cisco.com/c/en/us/td/docs/security/firepower/

9300/compatibility/fxos-compatibility.html.
Procedure
Step 1 Enable the flow offload service.

You must reload the system whenever you enable or disable the service. Reboot is required to allocate the
extra CPU cores and virtual NICs (VNICs) required for offloading flows.
There are special considerations for changing the mode for clusters or failover pairs if you want a hitless
change:
• Clustering—First enable the service on the master unit, but do not reboot the master unit immediately.
Instead, reboot each member of the cluster first, then return to the master and reboot it. You can then
configure the offloading service policy on the master unit.
• Failover—First enable the service on the active unit, but do not reboot it immediately. Instead, reboot
the standby unit, then reboot the active unit. You can then configure the offloading service policy on
the active unit.
a) Select Configuration > Firewall > Advanced > Offload Engine.

b) Select Enable Offload Engine.
c) Click Apply.
d) Click Save to save your changes to the startup configuration.
e) Select Tools > System Reload to reboot the device.
Step 2 Create the service policy rule that identifies traffic that is eligible for offload.
a) Choose Configuration > Firewall > Service Policy.
b) Click Add > Add Service Policy Rule.
Alternatively, if you already have a rule for the hosts, edit the rule.
c) Select whether to apply the rule to a specific interface or globally to all interfaces, and click Next.
d) For Traffic Classification, matching by access-list (Source and Destination IP Addresses (uses ACL))
or port (TCP or UDP Destination Port) would be the most typical options. Select an option and click
Next.
e) Enter the ACL or port criteria. Click Next when finished.
For example, if you want to make all TCP traffic on the 10.1.1.0/255.255.255.224 subnet eligible for
offload, enter:
• Source = 10.1.1.0/255.255.255.224 (or 10.1.1.0/27)
• Destination = any
386
f) On the Rule Actions page, click the Connection Settings tab and select Flow Offload.
g) Click Finish to save the rule, and Apply to update the device.
Configure Connection Settings for Specific Traffic Classes (All Services)

You can configure different connection settings for specific traffic classes using service policies. Use service
policies to:
• Customize connection limits and timeouts used to protect against DoS and SYN-flooding attacks.
• Implement Dead Connection Detection so that valid but idle connections remain alive.
• Disable TCP sequence number randomization in cases where you do not need it.
• Customize how the TCP Normalizer protects against abnormal TCP packets.
• Implement TCP State Bypass for traffic subject to asynchronous routing. Bypass traffic is not subject
to inspection.
• Implement Stream Control Transmission Protocol (SCTP) State Bypass to turn off SCTP stateful
inspection.
• Implement flow offload to improve performance on supported hardware platforms.
• Decrement time-to-live (TTL) on packets so that the ASA will show up on trace route output.
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.
You can configure any combination of these settings for a given traffic class, except for TCP State Bypass
and TCP Normalizer customization, which are mutually exclusive.
Tip This procedure shows a service policy for traffic that goes through the ASA. You can also configure the
connection maximum and embryonic connection maximum for management (to the box) traffic.
Before You Begin

If you want to customize the TCP Normalizer, create the required TCP Map before proceeding.
Procedure
387
page.
• If you have a rule for which you are changing connection settings, select it and click Edit.
Step 2 On the Rule Actions wizard page or tab, select the Connection Settings tab.
Step 3 To set maximum connections, configure the following values in the Maximum Connections area:
• Maximum TCP, UDP and SCTP Connections—(TCP, UDP, SCTP.) The maximum number of
simultaneous connections for all clients in the traffic class, up to 2000000. The default is 0, which means
the maximum possible connections are allowed.
• Embryonic Connections—Specifies the maximum number of embryonic TCP connections per host up
to 2000000. An embryonic connection is a connection request that has not finished the necessary
handshake between source and destination. The default is 0, which means the maximum embryonic
connections are allowed. 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.
• Per Client Connections—(TCP, UDP, SCTP.) Specifies the maximum number of simultaneous
connections for each client up to 2000000. When a new connection is attempted by a client that already
has opened the maximum per-client number of connections, the ASA rejects the connection and drops
the packet.
• Per Client Embryonic Connections—Specifies the maximum number of simultaneous TCP embryonic
connections for each client up to 2000000. When a new TCP connection is requested by a client that
already has the maximum per-client number of embryonic connections open through the ASA, the ASA
prevents the connection.
Step 4 To configure connection timeouts, configure the following values in the TCP Timeout area:
• Embryonic Connection Timeout—The idle time until an embryonic (half-open) TCP connection slot
is freed. Enter 0:0:0 to disable timeout for the connection. The default is 30 seconds.
• Half Closed Connection Timeout—The idle timeout period until a half-closed connection is closed,
between 0:5:0 (for 9.1(1) and earlier) or 0:0:30 (for 9.1(2) and later) and 1193:0:0. The default is 0:10:0.
Half-closed connections are not affected by DCD. Also, the ASA does not send a reset when taking
down half-closed connections.
• Idle Connection Timeout—The idle time until a connection slot (of any protocol, not just TCP) is freed.
Enter 0:0:0 to disable timeout for the connection. This duration must be at least 5 minutes. The default
is 1 hour.
• Send reset to TCP endpoints before timeout—Whether the ASA should send a TCP reset message
to the endpoints of the connection before freeing the connection slot.
• Dead Connection Detection (DCD)—Whether to enable Dead Connection Detection (DCD). Before
expiring an idle connection, the ASA probes the end hosts to determine if the connection is valid. If both
hosts respond, the connection is preserved, otherwise the connection is freed. Set the maximum number
of retries (default is 5, the range is 1-255) and the retry interval, which is the period to wait after each
unresponsive DCD probe before sending another probe (0:0:1 to 24:0:0, default is 0:0:15).
Step 5 To disable randomized sequence numbers, uncheck Randomize Sequence Number.
388
Monitoring Connections
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.
Step 6 To customize TCP Normalizer behavior, check Use TCP Map and choose an existing TCP map from the
drop-down list (if available), or add a new one by clicking New.
Step 7 To decrement time-to-live (TTL) on packets that match the class, check Decrement time to live for a
connection.
Decrementing TTL is necessary for the ASA to show up in trace routes as one of the hops. You must also
increase the rate limit for ICMP Unreachable messages on Configuration > Device Management >
Management Access > ICMP.
Step 8 To enable TCP state bypass, check TCP State Bypass.

Step 9 To enable SCTP state bypass, check SCTP State Bypass.
Implement SCTP State Bypass to turn off SCTP stateful inspection. For more information, see SCTP Stateful
Step 10 (ASA on the FXOS chassis, FXOS 1.1.3 or later, only.) To enable flow offload, check Flow Offload.
Eligible traffic is offloaded to a super fast path, where the flows are switched in the NIC itself. You must also
enable the offload service. Select Configuration > Firewall > Advanced > Offload Engine.
Step 11 Click OK or Finish.
Monitoring Connections
Use the following pages to monitor connections:
• Home > Firewall Dashboard, and look at the Top Ten Protected Servers under SYN Attack dashboard
to monitor TCP Intercept. Click the Detailbutton to show history sampling data. The ASA samples the
number of attacks 30 times during the rate interval, so for the default 30 minute period, statistics are
collected every 60 seconds.
• Monitoring > Properties > Connections, to see current connections.
• Monitoring > Properties > Connection Graphs, to monitor performance.
In addition, you can enter the following commands using Tools > Command Line Interface.
• 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 flow-offload {info [detail] | cpu | flow [count | detail] | statistics}
Shows information about the flow offloading, including general status information, CPU usage for
offloading, offloaded flow counts and details, and offloaded flow statistics.
• show service-policy
Shows service policy statistics, including Dead Connection Detection (DCD) statistics.
• show threat-detection statistics top tcp-intercept [all | detail]
389
History for Connection Settings
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 ASA samples the number of attacks 30
times during the rate interval, so for the default 30 minute period, statistics are collected every 60 seconds.

TCP state bypass 8.2(1) This feature was introduced. The following command was introduced:
set connection advanced-options tcp-state-bypass.
Connection timeout for all protocols 8.2(2) The idle timeout was changed to apply to all protocols, not just TCP.
The following screen was modified: Configuration > Firewall > Service
Policies > Rule Actions > Connection Settings.
Timeout for connections using a backup 8.2(5)/8.4(2) When multiple static routes exist to a network with different metrics,
static route 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 take
advantage of this feature, change the timeout to a new value.
We modified the following screen: Configuration > Firewall >
Advanced > Global Timeouts.
Configurable timeout for PAT xlate 8.4(3) When a PAT xlate times out (by default after 30 seconds), and the
ASA reuses the port for a new translation, some upstream routers might
reject the new connection because the previous connection might still
be open on the upstream device. The PAT xlate timeout is now
configurable, to a value between 30 seconds and 5 minutes.
Advanced > Global Timeouts.
Increased maximum connection limits 9.0(1) The maximum number of connections for service policy rules was
for service policy rules increased from 65535 to 2000000.
We modified the following screen: Configuration > Firewall > Service
Policy Rules > Connection Settings.
Decreased the half-closed timeout 9.1(2) The half-closed timeout minimum value for both the global timeout
minimum value to 30 seconds and connection timeout was lowered from 5 minutes to 30 seconds to
provide better DoS protection.
Configuration > Firewall > Service Policy Rules > Connection Settings;
Configuration > Firewall > Advanced > Global Timeouts.
390

SCTP idle timeout and SCTP state 9.5(2) You can set an idle timeout for SCTP connections. You can also enable
bypass SCTP state bypass to turn off SCTP stateful inspection on a class of
traffic.
We modified the following screens: Configuration > Firewall >
Advanced > Global Timeouts; Configuration > Firewall > Service
Policy Rules wizard, Connection Settings tab.
Flow offload for the ASA on the 9.5(2.1) You can identify flows that should be offloaded from the ASA and
Firepower 9300. switched directly in the NIC (on the Firepower 9300). This provides
improved performance for large data flows in data centers.
This feature requires FXOS 1.1.3.
We added or modified the following screens: Configuration > Firewall
> Advanced > Offload Engine, the Rule Actions > Connection
Settings tab when adding or editing rules under Configuration >
Firewall > Service Policy Rules.
391
392
CHAPTER 17
Quality of Service
Have you ever participated in a long-distance phone call that involved a satellite connection? The conversation
might be interrupted with brief, but perceptible, gaps at odd intervals. Those gaps are the time, called the
latency, between the arrival of packets being transmitted over the network. Some network traffic, such as
voice and video, cannot tolerate long latency times. Quality of service (QoS) is a feature that lets you give
priority to critical traffic, prevent bandwidth hogging, and manage network bottlenecks to prevent packet
drops.
Note For the ASASM, we suggest performing QoS on the switch instead of the ASASM. Switches have more
capability in this area. In general, QoS is best performed on the routers and switches in the network, which
tend to have more extensive capabilities than the ASA.
The following topics describe how to apply QoS policies.
• About QoS, page 393

• Guidelines for QoS, page 395
• Configure QoS, page 396
• Monitor QoS, page 399
• History for QoS, page 401
About QoS
You should consider that in an ever-changing network environment, QoS is not a one-time deployment, but
an ongoing, essential part of network design.
This section describes the QoS features available on the ASA.
Supported QoS Features

The ASA supports the following QoS features:
• Policing—To prevent classified traffic from hogging the network bandwidth, you can limit the maximum
bandwidth used per class. See Policing, on page 394 for more information.
393
About QoS
• Priority queuing—For critical traffic that cannot tolerate latency, such as Voice over IP (VoIP), you can
identify traffic for Low Latency Queuing (LLQ) so that it is always transmitted ahead of other traffic.
See Priority Queuing, on page 394.
What is a Token Bucket?

A token bucket is used to manage a device that regulates the data in a flow, for example, a traffic policer. A
token bucket itself has no discard or priority policy. Rather, a token bucket discards tokens and leaves to the
flow the problem of managing its transmission queue if the flow overdrives the regulator.
A token bucket is a formal definition of a rate of transfer. It has three components: a burst size, an average
rate, and a time interval. Although the average rate is generally represented as bits per second, any two values
may be derived from the third by the relation shown as follows:
average rate = burst size / time interval
Here are some definitions of these terms:
• Average rate—Also called the committed information rate (CIR), it specifies how much data can be sent
or forwarded per unit time on average.
• Burst size—Also called the Committed Burst (Bc) size, it specifies in bytes per burst how much traffic
can be sent within a given unit of time to not create scheduling concerns.
• Time interval—Also called the measurement interval, it specifies the time quantum in seconds per burst.
In the token bucket metaphor, tokens are put into the bucket at a certain rate. The bucket itself has a specified
capacity. If the bucket fills to capacity, newly arriving tokens are discarded. Each token is permission for the
source to send a certain number of bits into the network. To send a packet, the regulator must remove from
the bucket a number of tokens equal in representation to the packet size.
If not enough tokens are in the bucket to send a packet, the packet waits until the packet is discarded or marked
down. If the bucket is already full of tokens, incoming tokens overflow and are not available to future packets.
Thus, at any time, the largest burst a source can send into the network is roughly proportional to the size of
the bucket.
Policing
Policing is a way of ensuring that no traffic exceeds the maximum rate (in bits/second) that you configure,
thus ensuring that no one traffic class can take over the entire resource. When traffic exceeds the maximum
rate, the ASA drops the excess traffic. Policing also sets the largest single burst of traffic allowed.
Priority Queuing
LLQ priority queuing lets you prioritize certain traffic flows (such as latency-sensitive traffic like voice and
video) ahead of other traffic. Priority queuing uses an LLQ priority queue on an interface (see Configure the
Priority Queue for an Interface, on page 397), while all other traffic goes into the “best effort” queue. Because
queues are not of infinite size, they can fill and overflow. When a queue is full, any additional packets cannot
get into the queue and are dropped. This is called tail drop. To avoid having the queue fill up, you can increase
the queue buffer size. You can also fine-tune the maximum number of packets allowed into the transmit queue.
These options let you control the latency and robustness of the priority queuing. Packets in the LLQ queue
are always transmitted before packets in the best effort queue.
394
Guidelines for QoS
How QoS Features Interact

You can configure each of the QoS features alone if desired for the ASA. Often, though, you configure multiple
QoS features on the ASA so you can prioritize some traffic, for example, and prevent other traffic from causing
bandwidth problems. You can configure:
Priority queuing (for specific traffic) + Policing (for the rest of the traffic).
You cannot configure priority queuing and policing for the same set of traffic.
DSCP (DiffServ) Preservation

DSCP (DiffServ) markings are preserved on all traffic passing through the ASA. The ASA does not locally
mark/remark any classified traffic. For example, you could key off the Expedited Forwarding (EF) DSCP bits
of every packet to determine if it requires “priority” handling and have the ASA direct those packets to the
LLQ.
Guidelines for QoS

Context Mode Guidelines
Supported in single context mode only. Does not support multiple context mode.
Firewall Mode Guidelines

Supported in routed firewall mode only. Does not support transparent firewall mode.
IPv6 Guidelines
Does not support IPv6.
Model Guidelines
• (ASA 5512-X through ASA 5555-X) Priority queuing is not supported on the Management 0/0 interface.
• (ASASM) Only policing is supported.

• QoS is applied unidirectionally; only traffic that enters (or exits, depending on the QoS feature) the
interface to which you apply the policy map is affected.
• For priority traffic, you cannot use the class-default class map.
• For priority queuing, the priority queue must be configured for a physical interface or, for the ASASM,
a VLAN.
• For policing, to-the-box traffic is not supported.
• For policing, traffic to and from a VPN tunnel bypasses interface policing.
• For policing, when you match a tunnel group class map, only outbound policing is supported.
395
Configure QoS
Configure QoS
Use the following sequence to implement QoS on the ASA.
Procedure
Step 1 Determine the Queue and TX Ring Limits for a Priority Queue, on page 396.
Step 2 Configure the Priority Queue for an Interface, on page 397.
Step 3 Configure a Service Rule for Priority Queuing and Policing, on page 398.
Determine the Queue and TX Ring Limits for a Priority Queue

Use the following worksheets to determine the priority queue and TX ring limits.
Queue Limit Worksheet

The following worksheet shows how to calculate the priority queue size. Because queues are not of infinite
size, they can fill and overflow. When a queue is full, any additional packets cannot get into the queue and
are dropped (called tail drop). To avoid having the queue fill up, you can adjust the queue buffer size according
to Configure the Priority Queue for an Interface, on page 397.
Tips on the worksheet:
• Outbound bandwidth—For example, DSL might have an uplink speed of 768 Kbps. Check with your
provider.
• Average packet size—Determine this value from a codec or sampling size. For example, for VoIP over
VPN, you might use 160 bytes. We recommend 256 bytes if you do not know what size to use.
• Delay—The delay depends on your application. For example, the recommended maximum delay for
VoIP is 200 ms. We recommend 500 ms if you do not know what delay to use.
Table 15: Queue Limit Worksheet
1 __________ Mbps x 125 = __________

Outbound # of bytes/ms
bandwidth
(Mbps or Kbps) Kbps x .125 = __________
# of bytes/ms
2 ___________ ÷ __________ x __________ = __________

# of bytes/ms Average packet Delay (ms) Queue limit (# of
from Step 1 size (bytes) packets)
396
Configure QoS
TX Ring Limit Worksheet

The following worksheet shows how to calculate the TX ring limit. This limit determines the maximum
number of packets allowed into the Ethernet transmit driver before the driver pushes back to the queues on
the interface to let them buffer packets until the congestion clears. This setting guarantees that the
hardware-based transmit ring imposes a limited amount of extra latency for a high-priority packet.
Tips on the worksheet:
• Outbound bandwidth—For example, DSL might have an uplink speed of 768 Kbps. Check with your
provider.
• Maximum packet size—Typically, the maximum size is 1538 bytes, or 1542 bytes for tagged Ethernet.
If you allow jumbo frames (if supported for your platform), then the packet size might be larger.
• Delay—The delay depends on your application. For example, to control jitter for VoIP, you should use
20 ms.
Table 16: TX Ring Limit Worksheet
1 __________ Mbps x 125 = __________

Outbound # of bytes/ms
bandwidth
(Mbps or Kbps) Kbps x 0.125 = __________
# of bytes/ms
2 ___________ ÷ __________ x __________ = __________

# of bytes/ms Maximum packet Delay (ms) TX ring limit (# of
from Step 1 size (bytes) packets)
Configure the Priority Queue for an Interface

If you enable priority queuing for traffic on a physical interface, then you need to also create the priority queue
on each interface. Each physical interface uses two queues: one for priority traffic, and the other for all other
traffic. For the other traffic, you can optionally configure policing.
Before You Begin

• (ASASM) The ASASM does not support priority queuing.
• (ASA 5512-X through ASA 5555-X) Priority queuing is not supported on the Management 0/0 interface.
Procedure
Step 1 Choose Configuration > Device Management > Advanced > Priority Queue, and click Add.
Step 2 Configure the following options:
397
Configure QoS
• Interface—The physical interface name on which you want to enable the priority queue, or for the
ASASM, the VLAN interface name.
• Queue Limit—The number of average, 256-byte packets that the specified interface can transmit in a
500-ms interval. The range is 0-2048, and 2048 is the default.
A packet that stays more than 500 ms in a network node might trigger a timeout in the end-to-end
application. Such a packet can be discarded in each network node.
Because queues are not of infinite size, they can fill and overflow. When a queue is full, any additional
packets cannot get into the queue and are dropped (called tail drop). To avoid having the queue fill up,
you can use this option to increase the queue buffer size.
The upper limit of the range of values for this option is determined dynamically at run time. The key
determinants are the memory needed to support the queues and the memory available on the device.
The Queue Limit that you specify affects both the higher priority low-latency queue and the best effort
queue.
• Transmission Ring Limit—The depth of the priority queues, which is the number of maximum 1550-byte
packets that the specified interface can transmit in a 10-ms interval. The range is 3-511, and 511 is the
default.
This setting guarantees that the hardware-based transmit ring imposes no more than 10-ms of extra
latency for a high-priority packet.
This option sets the maximum number of low-latency or normal priority packets allowed into the Ethernet
transmit driver before the driver pushes back to the queues on the interface to let them buffer packets
until the congestion clears.
The upper limit of the range of values is determined dynamically at run time. The key determinants are
the memory needed to support the queues and the memory available on the device.
The Transmission Ring Limit that you specify affects both the higher priority low-latency queue and
the best-effort queue.
Step 3 Click OK, then Apply.
Configure a Service Rule for Priority Queuing and Policing

You can configure priority queuing and policing for different class maps within the same policy map. See
How QoS Features Interact, on page 395 for information about valid QoS configurations.
Before You Begin

• You cannot use the class-default class map for priority traffic.
• (ASASM) The ASASM only supports policing.
• For policing, to-the-box traffic is not supported.
• For policing, traffic to and from a VPN tunnel bypasses interface policing.
• For policing, when you match a tunnel group class map, only outbound policing is supported.
• For priority traffic, identify only latency-sensitive traffic.
• For policing traffic, you can choose to police all other traffic, or you can limit the traffic to certain types.
398
Monitor QoS
Procedure
You can configure QoS as part of a new service policy rule, or you can edit an existing service policy.
Step 2 Proceed through the wizard to the Rules page, selecting the interface (or global) and traffic matching criteria
along the way.
For policing traffic, you can choose to police all traffic that you are not prioritizing, or you can limit the traffic
to certain types.
Tip If you use an ACL for traffic matching, policing is applied in the direction specified in the ACL only.
That is, traffic going from the source to the destination is policed, but not the reverse.
Step 3 In the Rule Actions dialog box, click the QoS tab.
Step 4 Select Enable priority for this flow.
If this service policy rule is for an individual interface, ASDM automatically creates the priority queue for
the interface (Configuration > Device Management > Advanced > Priority Queue; for more information, see
Configure the Priority Queue for an Interface, on page 397). If this rule is for the global policy, then you need
to manually add the priority queue to one or more interfaces before you configure the service policy rule.
Step 5 Select Enable policing, then check the Input policing or Output policing (or both) check boxes to enable
the specified type of traffic policing. For each type of traffic policing, configure the following options:
• Committed Rate—The rate limit for this traffic flow; this is a value in the range 8000-2000000000,
specifying the maximum speed (bits per second) allowed.
• Conform Action—The action to take when the rate is less than the conform-burst value. Values are
transmit or drop.
• Exceed Action—Take this action when the rate is between the conform-rate value and the conform-burst
value. Values are transmit or drop.
• Burst Rate—A value in the range 1000-512000000, specifying the maximum number of instantaneous
bytes allowed in a sustained burst before throttling to the conforming rate value.
Step 6 Click Finish, then Apply.
Monitor QoS
The following topics explain how to monitor QoS.
To monitor QoS in ASDM, you can enter commands at the Command Line Interface tool.
QoS Police Statistics

To view the QoS statistics for traffic policing, use the show service-policy police command.
hostname# show service-policy police
Global policy:
Service-policy: global_fw_policy
399
Monitor QoS
Interface outside:
Service-policy: qos
Class-map: browse
police Interface outside:
cir 56000 bps, bc 10500 bytes
conformed 10065 packets, 12621510 bytes; actions: transmit
exceeded 499 packets, 625146 bytes; actions: drop
conformed 5600 bps, exceed 5016 bps
Class-map: cmap2
police Interface outside:
cir 200000 bps, bc 37500 bytes
conformed 17179 packets, 20614800 bytes; actions: transmit
exceeded 617 packets, 770718 bytes; actions: drop
conformed 198785 bps, exceed 2303 bps
QoS Priority Statistics

To view statistics for service policies implementing the priority command, use the show service-policy
priority command.
hostname# show service-policy priority

Global policy:
Service-policy: global_fw_policy
Interface outside:
Service-policy: qos
Class-map: TG1-voice
Priority:
Interface outside: aggregate drop 0, aggregate transmit 9383
“Aggregate drop” denotes the aggregated drop in this interface; “aggregate transmit” denotes the aggregated
number of transmitted packets in this interface.
QoS Priority Queue Statistics

To display the priority-queue statistics for an interface, use the show priority-queue statistics command.
The results show the statistics for both the best-effort (BE) queue and the low-latency queue (LLQ). The
following example shows the use of the show priority-queue statistics command for the interface named
test.
hostname# show priority-queue statistics test
Priority-Queue Statistics interface test
Queue Type = BE
Packets Dropped = 0
Packets Transmit = 0
Packets Enqueued = 0
Current Q Length = 0
Max Q Length = 0
Queue Type = LLQ

Packets Dropped = 0
Packets Transmit = 0
Packets Enqueued = 0
Current Q Length = 0
Max Q Length = 0
hostname#
In this statistical report:

• “Packets Dropped” denotes the overall number of packets that have been dropped in this queue.
400
History for QoS
• “Packets Transmit” denotes the overall number of packets that have been transmitted in this queue.
• “Packets Enqueued” denotes the overall number of packets that have been queued in this queue.
• “Current Q Length” denotes the current depth of this queue.
• “Max Q Length” denotes the maximum depth that ever occurred in this queue.
History for QoS

Feature Name Platform Description
Releases
Priority queuing and policing 7.0(1) We introduced QoS priority queuing and policing.
Configuration > Device Management > Advanced > Priority
Queue Configuration > Firewall > Service Policy Rules
Shaping and hierarchical priority queuing 7.2(4)/8.0(4) We introduced QoS shaping and hierarchical priority queuing.
Service Policy Rules.
Ten Gigabit Ethernet support for a standard priority 8.2(3)/8.4(1) We added support for a standard priority queue on Ten Gigabit
queue on the ASA 5585-X Ethernet interfaces for the ASA 5585-X.
401
History for QoS
402
CHAPTER 18
Threat Detection
The following topics describe how to configure threat detection statistics and scanning threat detection.
• Detecting Threats, page 403

• Guidelines for Threat Detection, page 405
• Defaults for Threat Detection, page 406
• Configure Threat Detection, page 407
• Monitoring Threat Detection, page 409
• History for Threat Detection, page 410
Detecting Threats
Threat detection on the ASA provides a front-line defense against attacks. Threat detection works at Layer 3
and 4 to develop a baseline for traffic on the device, analyzing packet drop statistics and accumulating “top”
reports based on traffic patterns. In comparison, a module that provides IPS or Next Generation IPS services
identifies and mitigates attack vectors up to Layer 7 on traffic the ASA permitted, and cannot see the traffic
dropped already by the ASA. Thus, threat detection and IPS can work together to provide a more comprehensive
threat defense.
Threat detection consists of the following elements:
• Different levels of statistics gathering for various threats.
Threat detection statistics can help you manage threats to your ASA; for example, if you enable scanning
threat detection, then viewing statistics can help you analyze the threat. You can configure two types of
threat detection statistics:
◦Basic threat detection statistics—Includes information about attack activity for the system as a
whole. Basic threat detection statistics are enabled by default and have no performance impact.
◦Advanced threat detection statistics—Tracks activity at an object level, so the ASA can report
activity for individual hosts, ports, protocols, or ACLs. Advanced threat detection statistics can
have a major performance impact, depending on the statistics gathered, so only the ACL statistics
are enabled by default.
403
Detecting Threats
• Scanning threat detection, which determines when a host is performing a scan. You can optionally shun
any hosts determined to be a scanning threat.
Basic Threat Detection Statistics

Using basic threat detection statistics, the ASA monitors the rate of dropped packets and security events due
to the following reasons:
• Denial by ACLs.
• Bad packet format (such as invalid-ip-header or invalid-tcp-hdr-length).
• Connection limits exceeded (both system-wide resource limits, and limits set in the configuration).
• DoS attack detected (such as an invalid SPI, Stateful Firewall check failure).
• Basic firewall checks failed. This option is a combined rate that includes all firewall-related packet drops
in this list. It does not include non-firewall-related drops such as interface overload, packets failed at
application inspection, and scanning attack detected.
• Suspicious ICMP packets detected.
• Packets failed application inspection.
• Interface overload.
• Scanning attack detected. This option monitors scanning attacks; for example, the first TCP packet is
not a SYN packet, or the TCP connection failed the 3-way handshake. Full scanning threat detection
takes this scanning attack rate information and acts on it by classifying hosts as attackers and automatically
shunning them, for example.
• Incomplete session detection such as TCP SYN attack detected or UDP session with no return data attack
detected.
When the ASA detects a threat, it immediately sends a system log message (733100). The ASA tracks two
types of rates: the average event rate over an interval, and the burst event rate over a shorter burst interval.
The burst rate interval is 1/30th of the average rate interval or 10 seconds, whichever is higher. For each
received event, the ASA checks the average and burst rate limits; if both rates are exceeded, then the ASA
sends two separate system messages, with a maximum of one message for each rate type per burst period.
Basic threat detection affects performance only when there are drops or potential threats; even in this scenario,
the performance impact is insignificant.
Advanced Threat Detection Statistics

Advanced threat detection statistics show both allowed and dropped traffic rates for individual objects such
as hosts, ports, protocols, or ACLs.
Caution Enabling advanced statistics can affect the ASA performance, depending on the type of statistics enabled.
Enabling host statistics affects performance in a significant way; if you have a high traffic load, you might
consider enabling this type of statistics temporarily. Port statistics, however, has modest impact.
404
Guidelines for Threat Detection
Scanning Threat Detection

A typical scanning attack consists of a host that tests the accessibility of every IP address in a subnet (by
scanning through many hosts in the subnet or sweeping through many ports in a host or subnet). The scanning
threat detection feature determines when a host is performing a scan. Unlike IPS scan detection that is based
on traffic signatures, ASA threat detection scanning maintains an extensive database that contains host statistics
that can be analyzed for scanning activity.
The host database tracks suspicious activity such as connections with no return activity, access of closed
service ports, vulnerable TCP behaviors such as non-random IPID, and many more behaviors.
If the scanning threat rate is exceeded, then the ASA sends a syslog message (733101), and optionally shuns
the attacker. The ASA tracks two types of rates: the average event rate over an interval, and the burst event
rate over a shorter burst interval. The burst event rate is 1/30th of the average rate interval or 10 seconds,
whichever is higher. For each event detected that is considered to be part of a scanning attack, the ASA checks
the average and burst rate limits. If either rate is exceeded for traffic sent from a host, then that host is considered
to be an attacker. If either rate is exceeded for traffic received by a host, then that host is considered to be a
target.
The following table lists the default rate limits for scanning threat detection.
Table 17: Default Rate Limits for Scanning Threat Detection
Average Rate Burst Rate

5 drops/sec over the last 600 seconds. 10 drops/sec over the last 20 second period.
5 drops/sec over the last 3600 seconds. 10 drops/sec over the last 120 second period.
Caution The scanning threat detection feature can affect the ASA performance and memory significantly while it
creates and gathers host- and subnet-based data structure and information.
Guidelines for Threat Detection

Security Context Guidelines
Except for advanced threat statistics, threat detection is supported in single mode only. In Multiple mode,
TCP Intercept statistics are the only statistic supported.
Types of Traffic Monitored

• Only through-the-box traffic is monitored; to-the-box traffic is not included in threat detection.
• Traffic that is denied by an ACL does not trigger scanning threat detection; only traffic that is allowed
through the ASA and that creates a flow is affected by scanning threat detection.
405
Defaults for Threat Detection
Defaults for Threat Detection

Basic threat detection statistics are enabled by default.
The following table lists the default settings. You can view all these default settings using the show
running-config all threat-detection command in Tools > Command Line Interface.
For advanced statistics, by default, statistics for ACLs are enabled.
Table 18: Basic Threat Detection Default Settings
Trigger Settings
Packet Drop Reason Average Rate Burst Rate
100 drops/sec over the last 600 400 drops/sec over the last 20
• DoS attack detected seconds. second period.
• Bad packet format
• Connection limits exceeded seconds. second period.
• Suspicious ICMP packets
detected
Scanning attack detected 5 drops/sec over the last 600 10 drops/sec over the last 20
seconds. second period.
Incomplete session detected such as 100 drops/sec over the last 600 200 drops/sec over the last 20
TCP SYN attack detected or UDP seconds. second period.
session with no return data attack
detected (combined) 80 drops/sec over the last 3600 160 drops/sec over the last 120
Denial by ACLs 400 drops/sec over the last 600 800 drops/sec over the last 20
• Basic firewall checks failed seconds. second period.
• Packets failed application
inspection 320 drops/sec over the last 3600 1280 drops/sec over the last 120
406
Configure Threat Detection
Trigger Settings
Packet Drop Reason Average Rate Burst Rate
Interface overload 2000 drops/sec over the last 600 8000 drops/sec over the last 20
1600 drops/sec over the last 6400 drops/sec over the last 120
3600 seconds. second period.

Basic threat detection statistics are enabled by default, and might be the only threat detection service that you
need. Use the following procedure if you want to implement additional threat detection services.
Procedure
Step 1 Configure Basic Threat Detection Statistics, on page 407.

Basic threat detection statistics include activity that might be related to an attack, such as a DoS attack.
Step 2 Configure Advanced Threat Detection Statistics, on page 407.

Step 3 Configure Scanning Threat Detection, on page 408.
Configure Basic Threat Detection Statistics

Basic threat detection statistics is enabled by default. You can disabled it, or turn it on again if you disable it.
Procedure
Step 1 Choose the Configuration > Firewall > Threat Detection.

Step 2 Select or deselect Enable Basic Threat Detection as desired.
Step 3 Click Apply.
Configure Advanced Threat Detection Statistics

You can configure the ASA to collect extensive statistics. By default, statistics for ACLs are enabled. To
enable other statistics, perform the following steps.
Procedure
Step 1 Choose Configuration > Firewall > Threat Detection.

Step 2 In the Scanning Threat Statistics area, choose one of the following options:
407
• Enable All Statistics.

• Disable All Statistics.
• Enable Only Following Statistics.
Step 3 If you chose Enable Only Following Statistics, then select one or more of the following options:
• Hosts—Enables host statistics. The host statistics accumulate for as long as the host is active and in the
scanning threat host database. The host is deleted from the database (and the statistics cleared) after 10
minutes of inactivity.
• Access Rules (enabled by default)—Enables statistics for access rules.
• Port—Enables statistics for TCP and UDP ports.
• Protocol—Enables statistics for non-TCP/UDP IP protocols.
• TCP-Intercept—Enables statistics for attacks intercepted by TCP Intercept (to enable TCP Intercept,
see Protect Servers from a SYN Flood DoS Attack (TCP Intercept), on page 377).
Step 4 For host, port, and protocol statistics, you can change the number of rate intervals collected. In the Rate
Intervals area, choose 1 hour, 1 and 8 hours, or 1, 8 and 24 hours for each statistics type. The default interval
is 1 hour, which keeps the memory usage low.
Step 5 For TCP Intercept statistics, you can set the following options in the TCP Intercept Threat Detection area:
• Monitoring Window Size—Sets the size of the history monitoring window, between 1 and 1440 minutes.
The default is 30 minutes. The ASA samples the number of attacks 30 times during the rate interval, so
for the default 30 minute period, statistics are collected every 60 seconds.
• Burst Threshold Rate—Sets the threshold for syslog message generation, between 25 and 2147483647.
The default is 400 per second. When the burst rate is exceeded, syslog message 733104 is generated.
• Average Threshold Rate—Sets the average rate threshold for syslog message generation, between 25
and 2147483647. The default is 200 per second. When the average rate is exceeded, syslog message
733105 is generated.
Click Set Default to restore the default values.
Step 6 Click Apply.
Configure Scanning Threat Detection

You can configure scanning threat detection to identify attackers and optionally shun them.
Procedure
Step 1 Choose Configuration > Firewall > Threat Detection.

Step 2 Select Enable Scanning Threat Detection.
Step 3 (Optional) To automatically terminate a host connection when the ASA identifies the host as an attacker,
select Shun Hosts detected by scanning threat and fill in these options if desired:
408
Monitoring Threat Detection
• To exempt host IP addresses from being shunned, enter an address or the name of a network object in
the Networks excluded from shun field. You can enter multiple addresses or subnets separated by
commas. To choose a network from the list of IP address objects, click the ... button.
• To set the duration of a shun for an attacking host, select Set Shun Duration and enter a value between
10 and 2592000 seconds. The default length is 3600 seconds (1 hour). To restore the default value, click
Set Default.
Step 4 Click Apply.
Monitoring Threat Detection

The following topics explain how to monitor threat detection and view traffic statistics.
Monitoring Basic Threat Detection Statistics

Choose Home > Firewall Dashboard > Traffic Overview to view basic threat detection statistics.
Monitoring Advanced Threat Detection Statistics

You can monitor advanced threat statistics using the following dashboards:
• Home > Firewall Dashboard > Top 10 Access Rules—Displays the most hit access rules. Permits and
denies are not differentiated in this graph. You can track denied traffic in the Traffic Overview >
Dropped Packets Rate graph.
• Home > Firewall Dashboard > Top Usage Statistics—The Top 10 Sources and Top 10 Destinations
tabs show statistics for hosts. Due to the threat detection algorithm, an interface used as a combination
failover and state link could appear in the top 10 hosts; this is expected behavior, and you can ignore
this IP address in the display.
The Top 10 Services tab shows statistics for both ports and protocols (both must be enabled for the
display), and shows the combined statistics of TCP/UDP port and IP protocol types. TCP (protocol 6)
and UDP (protocol 17) are not included in the display for IP protocols; TCP and UDP ports are, however,
included in the display for ports. If you only enable statistics for one of these types, port or protocol,
then you will only view the enabled statistics.
• Home > Firewall Dashboard > Top Ten Protected Servers under SYN Attack—Shows the TCP
Intercept statistics. Click the Detail button to show history sampling data. The ASA samples the number
of attacks 30 times during the rate interval, so for the default 30 minute period, statistics are collected
every 60 seconds.
409
History for Threat Detection
History for Threat Detection

Feature Name Platform Description
Releases
Basic and advanced threat detection statistics, 8.0(2) Basic and advanced threat detection statistics, scanning threat
scanning threat detection detection was introduced.
The following screens were introduced: Configuration >
Firewall > Threat Detection, Home > Firewall Dashboard
> Traffic Overview, Home > Firewall Dashboard > Top 10
Access Rules, Home > Firewall Dashboard > Top Usage
Status, Home > Firewall Dashboard > Top 10 Protected
Servers Under SYN Attack.
Shun duration 8.0(4)/8.1(2) You can now set the shun duration,
The following screens was modified: Configuration > Firewall
> Threat Detection.
TCP Intercept statistics 8.0(4)/8.1(2) TCP Intercept statistics were introduced.

The following screens were introduced or modified:
Configuration > Firewall > Threat Detection, Home >
Firewall Dashboard > Top 10 Protected Servers Under SYN
Attack.
Customize host statistics rate intervals 8.1(2) You can now customize the number of rate intervals for which
statistics are collected. The default number of rates was changed
from 3 to 1.
The following screen was modified: Configuration > Firewall
> Threat Detection.
Burst rate interval changed to 1/30th of the average 8.2(1) In earlier releases, the burst rate interval was 1/60th of the
rate. average rate. To maximize memory usage, the sampling interval
was reduced to 30 times during the average rate.
Customize port and protocol statistics rate intervals 8.3(1) You can now customize the number of rate intervals for which
statistics are collected. The default number of rates was changed
from 3 to 1.
The following screen was modified: Configuration > Firewall
> Threat Detection.
Improved memory usage 8.3(1) The memory usage for threat detection was improved.
410

Asdm 75 Firewall Config

Uploaded by

Copyright:

Available Formats

Asdm 75 Firewall Config

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Asdm 75 Firewall Config

Uploaded by

Copyright:

Available Formats

ASDM Book 2: Cisco ASA Series Firewall ASDM Configuration Guide,

© 2005-2015 Cisco Systems, Inc. All rights reserved.

Preface About This Guide xvii

CHAPTER 1 Introduction to Cisco ASA Firewall Services 1

PART I Access Control 9

CHAPTER 2 Access Rules 11

Extended Access Rules 14

CHAPTER 3 Objects for Access Control 29

CHAPTER 4 Access Control Lists 37

CHAPTER 5 Identity Firewall 55

Configure Identity Options 67

CHAPTER 6 ASA and Cisco TrustSec 73

CHAPTER 7 ASA FirePOWER Module 95

About the ASA FirePOWER Module 95

Shut Down the Module 118

CHAPTER 8 ASA and Cisco Cloud Web Security 125

PART II Network Address Translation 147

CHAPTER 9 Network Address Translation (NAT) 149

Static NAT 187

CHAPTER 10 NAT Examples and Reference 211

Determining the Egress Interface 243

PART III Service Policies and Application Inspection 263

CHAPTER 11 Service Policy 265

CHAPTER 12 Getting Started with Application Layer Protocol Inspection 281

Application Layer Protocol Inspection 281

CHAPTER 13 Inspection of Basic Internet Protocols 299

Defaults for IP Options Inspection 316

CHAPTER 14 Inspection for Voice and Video Protocols 331

MGCP Inspection Overview 336

CHAPTER 15 Inspection for Mobile Networks 351

Configure a Diameter Inspection Policy Map 361

PART IV Connection Management and Threat Detection 371

CHAPTER 16 Connection Settings 373

CHAPTER 17 Quality of Service 393

What is a Token Bucket? 394

CHAPTER 18 Threat Detection 403

• Document Objectives, page xvii

{x | y | z} Required alternative keywords are grouped in braces and separated by vertical

[] Elements in square brackets are optional.

[x | y | z] Optional alternative keywords are grouped in square brackets and separated by

[] Default responses to system prompts are also in square brackets.

<> Non-printing characters such as passwords are in angle brackets.

Obtaining Documentation and Submitting a Service Request

• How to Implement Firewall Services, page 1

How to Implement Firewall Services

Before You Begin

Basic Access Control

Network Address Translation

• Service Policy, on page 265

Use Case: Expose a Server to the Public

Figure 1: Static NAT for an Inside Web Server

Step 1 Choose Configuration > Firewall > Public Servers.

The following shows how the dialog box should look.

Step 4 Click OK, then click Apply.

• Controlling Network Access, page 11

Controlling Network Access

General Information About Rules

Interface Access Rules and Global Access Rules

Inbound and Outbound Rules

Figure 2: Outbound ACL