Hardware and Software Compatibility
For a complete list of supported hardware and software, see Cisco ASA Compatibility.
Introduction to the ASA
The ASA provides advanced stateful firewall and VPN concentrator functionality in one device. The ASA includes many advanced features, such as multiple security contexts (similar to virtualized firewalls), clustering (combining multiple firewalls into a single firewall), transparent (Layer 2) firewall or routed (Layer 3) firewall operation, advanced inspection engines, IPsec VPN, SSL VPN, and clientless SSL VPN support, and many more features.
VPN Compatibility
New Features
This section lists new features for each release.
 Note |
New, changed, and deprecated syslog messages are listed in the syslog message guide. |
New Features in ASA 9.17(1)
Released: December 1, 2021
|
Feature |
Description |
|---|---|
|
Platform Features |
|
|
Secure Firewall 3100 |
We introduced the ASA for the Secure Firewall 3110, 3120, 3130, and 3140. The Secure Firewall 3100 supports up to 8 units for Spanned EtherChannel clustering. You can hot swap a network module of the same type while the firewall is powered up without having to reboot; making other module changes requires a reboot. Secure Firewall 3100 25 Gbps interfaces support Forward Error Correction as well as speed detection based on the SFP installed. The SSDs are self-encrypting drives (SEDs), and if you have 2 SSDs, they form a software RAID. New/Modified commands: fec, netmod, speed sfp-detect, raid, show raid, show ssd |
|
ASAv support for Autoscale |
The ASAv now supports Autoscale for the following Public Cloud offerings:
Autoscaling increases or decreases the number of ASAv application instances based on capacity requirements. |
|
ASAv for AWS expanded instance support |
The ASAv on the AWS Public Cloud now supports AWS Nitro System instances from different Nitro instance families. ASAv for AWS adds support for these instances:
For a detailed list of supported instances, see the Cisco Adaptive Security Virtual Appliance (ASAv) Data Sheet. |
|
ASAv for Azure expanded instance support |
ASAv on the Azure Public Cloud now supports these instances:
For a detailed list of supported instances, see the Cisco Adaptive Security Virtual Appliance (ASAv) Data Sheet. |
|
Intel QuickAssist Technology (QAT) on ASAv |
The ASAv supports hardware crypto acceleration for ASAv deployments that use the Intel QuickAssist (QAT) 8970 PCI adapter. Hardware crypto acceleration for the ASAv using QAT is supported on VMware ESXi and KVM only. |
|
Single Root I/O Virtualization (SR-IOV) support for ASAv on OCI. |
You can now implement Single Root Input/Output Virtualization (SR-IOV) for ASAv on OCI. SR-IOV can provide performance improvements for ASAv. Mellanox 5 as vNICs are not supported in SR-IOV mode. |
|
Firewall Features |
|
|
Twice NAT support for fully-qualified domain name (FQDN) objects as the translated (mapped) destination |
You can use an FQDN network object, such as one specifying www.example.com, as the translated (mapped) destination address in twice NAT rules. The system configures the rule based on the IP address returned from the DNS server. |
|
Network-service objects and their use in policy-based routing and access control |
You can configure network-service objects and use them in extended access control lists for use in policy-based routing route maps and access control groups. Network-service objects include IP subnet or DNS domain name specifications, and optionally protocol and port specifications, that essentially combine network and service objects. This feature also includes the ability to define trusted DNS servers, to ensure that any DNS domain name resolutions acquire IP addresses from trusted sources. We added or modified the following commands: access-list extended , app-id , clear configure object network-service , clear configure object-group network-service , clear dns ip-cache , clear object , clear object-group , debug network-service , description , dns trusted-source , domain , network-service-member , network-service reload , object-group network-service , object network-service , policy-route cost , set adaptive-interface cost , show asp table classify , show asp table network-service , show dns trusted-source , show dns ip-cache , show object , show object-group , show running-config , subnet . |
|
High Availability and Scalability Features |
|
|
ASAv30, ASAv50, and ASAv100 clustering for VMware and KVM |
ASAv clustering lets you group up to 16 ASAvs together as a single logical device. A cluster provides all the convenience of a single device (management, integration into a network) while achieving the increased throughput and redundancy of multiple devices. ASAv clustering supports Individual Interface mode in routed firewall mode; Spanned EtherChannels are not supported. The ASAv uses a VXLAN virtual interface (VNI) for the cluster control link. New/Modified commands: cluster-interface vni, nve-only cluster, peer-group, show cluster info, show cluster info instance-type, show nve 1 |
|
Clearing routes in a high availability group or cluster |
In previous releases, the clear route command cleared the routing table on the unit only. Now, when operating in a high availability group or cluster, the command is available on the active or control unit only, and clears the routing table on all units in the group or cluster. We changed the clear route command. |
|
Interface Features |
|
|
Geneve interface support for the ASAv |
Geneve encapsulation support was added for the ASAv30, ASAv50, and ASAv100 to support single-arm proxy for the AWS Gateway Load Balancer. New/Modified commands: debug geneve, debug nve, debug vxlan, encapsulation, packet-tracer geneve, proxy single-arm, show asp drop, show capture, show interface, show nve |
|
Secure Firewall 3100 auto-negotiation can be enabled or disabled for 1Gigabit and higher interfaces. |
Secure Firewall 3100 auto-negotiation can be enabled or disabled for 1Gigabit and higher interfaces. For other model SFP ports, the no speed nonegotiate option sets the speed to 1000 Mbps; the new command means you can set auto-negotiation and speed independently. New/Modified commands: negotiate-auto |
|
Administrative and Troubleshooting Features |
|
|
Startup time and tmatch compilation status |
The show version command now includes information on how long it took to start (boot) up the system. Note that the larger the configuration, the longer it takes to boot up the system. The new show asp rule-engine command shows status on tmatch compilation. Tmatch compilation is used for an access list that is used as an access group, the NAT table, and some other items. It is an internal process that can consume CPU resources and impact performance while in progress, if you have very large ACLs and NAT tables. Compilation time depends on the size of the access list, NAT table, and so forth. |
|
Enhancements to show access-list element-count output and show tech-support content |
The output of the show access-list element-count has be enhanced to show the following:
In addition, the show tech-support output now includes the output show access-list element-count and show asp rule-engine . |
|
CiscoSSH stack |
The ASA uses a proprietary SSH stack for SSH connections. You can now choose to use the CiscoSSH stack instead, which is based on OpenSSH. The default stack continues to be the ASA stack. Cisco SSH supports:
Note that the CiscoSSH stack does not support:
If you need these features, you should continue to use the ASA SSH stack. There is a small change to SCP functionality with the CiscoSSH stack: to use the ASA copy command to copy a file to or from an SCP server, you have to enable SSH access on the ASA for the SCP server subnet/host using the ssh command. New/Modified commands: ssh stack ciscossh |
|
PCAP support in packet tracer |
You can replay a PCAP file in packet tracer tool and obtain the trace results. pcap and force are two new keywords that is used to support the usage of PCAP in packet tracer. New/Modified commands: packet-tracer input and show packet-tracer |
|
Stronger local user and enable password requirements |
For local users and the enable password, the following password requirements were added:
New/Modified commands: enable password , username |
|
Local user lockout changes |
The ASA can lock out local users after a configurable number of failed login attempts. This feature did not apply to users with privilege level 15. Also, a user would be locked out indefinitely until an admin unlocked their account. Now, users will be unlocked after 10 minutes unless an admin uses the clear aaa local user lockout command before then. Privilege level 15 users are also now affected by the lockout setting. New/Modified commands: aaa local authentication attempts max-fail , show aaa local user |
|
SSH and Telnet password change prompt |
The first time a local user logs into the ASA using SSH or Telnet, they are prompted to change their password. They will also be prompted for the first login after an admin changes their password. If the ASA reloads, however, users will not be prompted even if it is their first login. Note that any service that uses the local user database, such as VPN, will also have to use the new password if it was changed during an SSH or Telnet login. New/Modified commands: show aaa local user |
|
Monitoring Features |
|
|
SNMP now supports IPv6 when grouping multiple hosts in the form of a network object |
The host-group command of snmp-server now supports IPv6 host, range, and subnet objects. New/Modified commands: snmp-server host-group |
|
VPN Features |
|
|
Local tunnel id support for IKEv2 |
Support has been added for local Tunnel id configuration for IKEv2. New/Modified commands: set ikev2 local-identity |
|
Support for SAML Attributes with DAP constraint |
Support has been added for SAML assertion attributes which can be used to make DAP policy selections. It also introduces the ability for a group-policy to be specified by the cisco_group_policy attribute. |
|
Multiple SAML trustpoints in IDP configuration |
This feature supports adding multiple IDP trustpoints per SAML IDP configuration for applications that support multiple applications for the same Entity ID. New/Modified commands: saml idp-trustpoint <trustpoint-name> |
|
AnyConnect Client VPN SAML External Browser |
You can now configure VPN SAML External Browser to enable additional authentication choices, such as passwordless authentication, WebAuthN, FIDO2, SSO, U2F, and an improved SAML experience due to the persistence of cookies. When you use SAML as the primary authentication method for a remote access VPN connection profile, you can elect to have the AnyConnect Client use the client’s local browser instead of the AnyConnect Client embedded browser to perform the web authentication. This option enables single sign-on (SSO) between your VPN authentication and other corporate logins. Also choose this option if you want to support web authentication methods, such as biometric authentication and Yubikeys, that cannot be performed in the embedded browser. New/Modified commands: external-browser |
|
VPN Load balancing with SAML |
ASA now supports VPN load balancing with SAML authentication. |
Firewall Functional Overview
Firewalls protect inside networks from unauthorized access by users on an outside network. A firewall can also protect inside networks from each other, for example, by keeping a human resources network separate from a user network. If you have network resources that need to be available to an outside user, such as a web or FTP server, you can place these resources on a separate network behind the firewall, called a demilitarized zone (DMZ). The firewall allows limited access to the DMZ, but because the DMZ only includes the public servers, an attack there only affects the servers and does not affect the other inside networks. You can also control when inside users access outside networks (for example, access to the Internet), by allowing only certain addresses out, by requiring authentication or authorization, or by coordinating with an external URL filtering server.
When discussing networks connected to a firewall, the outside network is in front of the firewall, the inside network is protected and behind the firewall, and a DMZ, while behind the firewall, allows limited access to outside users. Because the ASA lets you configure many interfaces with varied security policies, including many inside interfaces, many DMZs, and even many outside interfaces if desired, these terms are used in a general sense only.
Security Policy Overview
A security policy determines which traffic is allowed to pass through the firewall to access another network. 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 actions to traffic to customize the security policy.
Permitting or Denying Traffic with Access Rules
You can apply access rules to limit traffic from inside to outside, or allow traffic from outside to inside. For bridge group interfaces, you can also apply an EtherType access rule to allow non-IP traffic.
Applying NAT
Some of the benefits of NAT include the following:
-
You can use private addresses on your inside networks. Private addresses are not routable on the Internet.
-
NAT hides the local addresses from other networks, so attackers cannot learn the real address of a host.
-
NAT can resolve IP routing problems by supporting overlapping IP addresses.
Protecting from IP Fragments
The ASA provides IP fragment protection. This feature performs full reassembly of all ICMP error messages and virtual reassembly of the remaining IP fragments that are routed through the ASA. Fragments that fail the security check are dropped and logged. Virtual reassembly cannot be disabled.
Applying HTTP, HTTPS, or FTP Filtering
Although you can use access lists to prevent outbound access to specific websites or FTP servers, configuring and managing web usage this way is not practical because of the size and dynamic nature of the Internet.
You can configure Cloud Web Security on the ASA. You can also use the ASA in conjunction with an external product such as the Cisco Web Security Appliance (WSA).
Applying Application 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.
Applying QoS Policies
Some network traffic, such as voice and streaming video, cannot tolerate long latency times. QoS is a network feature that lets you give priority to these types of traffic. QoS refers to the capability of a network to provide better service to selected network traffic.
Applying Connection Limits and TCP Normalization
You can limit TCP and UDP connections and embryonic connections. 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. An embryonic connection is a connection request that has not finished the necessary handshake between source and destination.
TCP normalization is a feature consisting of advanced TCP connection settings designed to drop packets that do not appear normal.
Enabling Threat Detection
You can configure scanning threat detection and basic threat detection, and also how to use statistics to analyze threats.
Basic threat detection detects activity that might be related to an attack, such as a DoS attack, and automatically sends a system log message.
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, the ASA scanning threat detection feature 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.
You can configure the ASA to send system log messages about an attacker or you can automatically shun the host.
Firewall Mode Overview
The ASA runs in two different firewall modes:
-
Routed
-
Transparent
In routed mode, the ASA is considered to be a router hop in the network.
In transparent mode, the ASA acts like a “bump in the wire,” or a “stealth firewall,” and is not considered a router hop. The ASA connects to the same network on its inside and outside interfaces in a "bridge group".
You might use a transparent firewall to simplify your network configuration. Transparent mode is also useful if you want the firewall to be invisible to attackers. You can also use a transparent firewall for traffic that would otherwise be blocked in routed mode. For example, a transparent firewall can allow multicast streams using an EtherType access list.
Routed mode supports Integrated Routing and Bridging, so you can also configure bridge groups in routed mode, and route between bridge groups and regular interfaces. In routed mode, you can replicate transparent mode functionality; if you do not need multiple context mode or clustering, you might consider using routed mode instead.
Stateful Inspection Overview
All traffic that goes through the ASA is inspected using the Adaptive Security Algorithm and either allowed through or dropped. A simple packet filter can check for the correct source address, destination address, and ports, but it does not check that the packet sequence or flags are correct. A filter also checks every packet against the filter, which can be a slow process.
Note |
The TCP state bypass feature allows you to customize the packet flow. |
A stateful firewall like the ASA, however, takes into consideration the state of a packet:
-
Is this a new connection?
If it is a new connection, the ASA has to check the packet against access lists and perform other tasks to determine if the packet is allowed or denied. To perform this check, the first packet of the session goes through the “session management path,” and depending on the type of traffic, it might also pass through the “control plane path.”
The session management path is responsible for the following tasks:
-
Performing the access list checks
-
Performing route lookups
-
Allocating NAT translations (xlates)
-
Establishing sessions in the “fast path”
The ASA creates forward and reverse flows in the fast path for TCP traffic; the ASA also creates connection state information for connectionless protocols like UDP, ICMP (when you enable ICMP inspection), so that they can also use the fast path.
Note
For other IP protocols, like SCTP, the ASA does not create reverse path flows. As a result, ICMP error packets that refer to these connections are dropped.
Some packets that require Layer 7 inspection (the packet payload must be inspected or altered) are passed on to the control plane path. Layer 7 inspection engines are required for protocols that have two or more channels: a data channel, which uses well-known port numbers, and a control channel, which uses different port numbers for each session. These protocols include FTP, H.323, and SNMP.
-
-
Is this an established connection?
If the connection is already established, the ASA does not need to re-check packets; most matching packets can go through the “fast” path in both directions. The fast path is responsible for the following tasks:
-
IP checksum verification
-
Session lookup
-
TCP sequence number check
-
NAT translations based on existing sessions
-
Layer 3 and Layer 4 header adjustments
Data packets for protocols that require Layer 7 inspection can also go through the fast path.
Some established session packets must continue to go through the session management path or the control plane path. Packets that go through the session management path include HTTP packets that require inspection or content filtering. Packets that go through the control plane path include the control packets for protocols that require Layer 7 inspection.
-
VPN Functional Overview
A VPN is a secure connection across a TCP/IP network (such as the Internet) that appears as a private connection. This secure connection is called a tunnel. The ASA uses tunneling protocols to negotiate security parameters, create and manage tunnels, encapsulate packets, transmit or receive them through the tunnel, and unencapsulate them. The ASA functions as a bidirectional tunnel endpoint: it can receive plain packets, encapsulate them, and send them to the other end of the tunnel where they are unencapsulated and sent to their final destination. It can also receive encapsulated packets, unencapsulate them, and send them to their final destination. The ASA invokes various standard protocols to accomplish these functions.
The ASA performs the following functions:
-
Establishes tunnels
-
Negotiates tunnel parameters
-
Authenticates users
-
Assigns user addresses
-
Encrypts and decrypts data
-
Manages security keys
-
Manages data transfer across the tunnel
-
Manages data transfer inbound and outbound as a tunnel endpoint or router
The ASA invokes various standard protocols to accomplish these functions.
Security Context Overview
You can partition a single ASA into multiple virtual devices, known as security contexts. Each context is an independent device, with its own security policy, interfaces, and administrators. Multiple contexts are similar to having multiple standalone devices. Many features are supported in multiple context mode, including routing tables, firewall features, IPS, and management; however, some features are not supported. See the feature chapters for more information.
In multiple context mode, the ASA includes a configuration for each context that identifies the security policy, interfaces, and almost all the options you can configure on a standalone device. The system administrator adds and manages contexts by configuring them in the system configuration, which, like a single mode configuration, is the startup configuration. The system configuration identifies basic settings for the ASA. The system configuration does not include any network interfaces or network settings for itself; rather, when the system needs to access network resources (such as downloading the contexts from the server), it uses one of the contexts that is designated as the admin context.
The admin context is just like any other context, except that when a user logs into the admin context, then that user has system administrator rights and can access the system and all other contexts.
ASA Clustering Overview
ASA Clustering lets you group multiple ASAs together as a single logical device. A cluster provides all the convenience of a single device (management, integration into a network) while achieving the increased throughput and redundancy of multiple devices.
You perform all configuration (aside from the bootstrap configuration) on the control unit only; the configuration is then replicated to the member units.
Special and Legacy Services
For some services, documentation is located outside of the main configuration guides and online help.
- Special Services Guides
-
Special services allow the ASA to interoperate with other Cisco products; for example, by providing a security proxy for phone services (Unified Communications), or by providing Botnet traffic filtering in conjunction with the dynamic database from the Cisco update server, or by providing WCCP services for the Cisco Web Security Appliance. Some of these special services are covered in separate guides:
- Legacy Services Guide
-
Legacy services are still supported on the ASA, however there may be better alternative services that you can use instead. Legacy services are covered in a separate guide:
Cisco ASA Legacy Feature Guide
This guide includes the following chapters:
-
Configuring RIP
-
AAA Rules for Network Access
-
Using Protection Tools, which includes Preventing IP Spoofing (ip verify reverse-path), Configuring the Fragment Size (fragment), Blocking Unwanted Connections (shun), Configuring TCP Options (for ASDM), and Configuring IP Audit for Basic IPS Support (ip audit).
-
Configuring Filtering Services
-
Feedback