Hardware and Software Compatibility
For a complete list of supported hardware and software, see Cisco ASA Compatibility.
- Introduction to the Cisco ASA
- Hardware and Software Compatibility
- VPN Compatibility
- New Features
- Firewall Functional Overview
- Security Policy Overview
- Permitting or Denying Traffic with Access Rules
- Applying NAT
- Protecting from IP Fragments
- Applying HTTP, HTTPS, or FTP Filtering
- Applying Application Inspection
- Sending Traffic to Supported Hardware or Software Modules
- Applying QoS Policies
- Applying Connection Limits and TCP Normalization
- Enabling Threat Detection
- Firewall Mode Overview
- Stateful Inspection Overview
- Security Policy Overview
- VPN Functional Overview
- Security Context Overview
- ASA Clustering Overview
- Special and Legacy Services
Introduction to the Cisco ASA
The Cisco ASA provides advanced stateful firewall and VPN concentrator functionality in one device as well as integrated services with add-on modules. 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.9(2)
Released: March 26, 2018
|
Feature |
Description |
||
|---|---|---|---|
|
Platform Features |
|||
|
ASAv support for VMware ESXi 6.5 |
The ASAv virtual platform supports hosts running on VMware ESXi 6.5. New VMware hardware versions have been added to the vi.ovf and esxi.ovf files to enable optimal performance and usability of the ASAv on ESXi 6.5. We did not modify any commands. |
||
|
ASAv support for VMXNET3 interfaces |
The ASAv virtual platform supports VMXNET3 interfaces on VMware hypervisors. We did not modify any commands. |
||
|
ASAv support for virtual serial console on first boot |
You can now configure the ASAv to use the virtual serial console on first boot, instead of the virtual VGA console, to access and configure the ASAv. New or Modified commands: console serial |
||
|
ASAv support to update user-defined routes in more than one Azure subscription for High Availability on Microsoft Azure |
You can now configure the ASAv in an Azure High Availability configuration to update user-defined routes in more than one Azure subscription. New or Modified commands: failover cloud route-table |
||
|
VPN Features |
|||
|
Remote Access VPN multi-context support extended to IKEv2 protocol |
Support for configuring ASA to allow Anyconnect and third party Standards-based IPSec IKEv2 VPN clients to establish Remote Access VPN sessions to ASA operating in multi-context mode. |
||
|
IPv6 connectivity to Radius Servers |
ASA 9.9.2 now supports IPv6 connectivity to external AAA Radius Servers. |
||
|
Easy VPN Enhancements for BVI Support |
Easy VPN has been enhanced to support a Bridged Virtual Interface (BVI) as its internal secure interface, and you can now directly configure which interface to use as the internal secure interface. Otherwise, the ASA chooses its internal secure interface using security levels. Also, management services, such as telnet, http, and ssh, can now be configured on a BVI if VPN management-access has been enabled on that BVI. For non-VPN management access, you should continue to configure these services on the bridge group member interfaces. New or Modified commands: vpnclient secure interface [interface-name], https, telnet, ssh, management-access |
||
|
Distributed VPN Session Improvements |
|
||
|
High Availability and Scalability Features |
|||
|
Automatically rejoin the cluster after an internal failure |
Formerly, many error conditions caused a cluster unit to be removed from the cluster, and you were required to manually rejoin the cluster after resolving the issue. Now, a unit will attempt to rejoin the cluster automatically at the following intervals by default: 5 minutes, 10 minutes, and then 20 minutes. These values are configurable. Internal failures include: application sync timeout; inconsistent application statuses; and so on. New or Modified commands: health-check system auto-rejoin, show cluster info auto-join |
||
|
Configurable debounce time to mark an interface as failed for the ASA 5000-X series |
You can now configure the debounce time before the ASA considers an interface to be failed and the unit is removed from the cluster on the ASA 5500-X series. This feature allows for faster detection of interface failures. Note that configuring a lower debounce time increases the chances of false-positives. When an interface status update occurs, the ASA waits the number of milliseconds specified before marking the interface as failed and the unit is removed from the cluster. The default debounce time is 500 ms, with a range of 300 ms to 9 seconds. This feature was previously available for the Firepower 4100/9300. New or modified command: health-check monitor-interface debounce-time |
||
|
Show transport related statistics for cluster reliable transport protocol messages |
You can now view per-unit cluster reliable transport buffer usage so you can identify packet drop issues when the buffer is full in the control plane. New or modified command: show cluster info transport cp detail |
||
|
Show failover history from peer unit |
You can now view failover history from the peer unit, using the details keyword . This includes failover state changes and reason for the state change. New or modified command: show failover |
||
|
Interface Features |
|||
|
Unique MAC address generation for single context mode |
You can now enable unique MAC address generation for VLAN subinterfaces in single context mode. Normally, subinterfaces share the same MAC address with the main interface. Because IPv6 link-local addresses are generated based on the MAC address, this feature allows for unique IPv6 link-local addresses. New or modified command: mac-address auto Also in 9.8(3) and 9.8(4). |
||
|
Administrative Features |
|||
|
RSA key pair supports 3072-bit keys |
You can now set the modulus size to 3072. New or modified command: crypto key generate rsa modulus |
||
|
The FXOS bootstrap configuration now sets the enable password |
When you deploy the ASA on the Firepower 4100/9300, the password setting in the bootstrap configuration now sets the enable password as well as the admin user password. Requires FXOS Version 2.3.1. |
||
|
Monitoring and Troubleshooting Features |
|||
|
SNMP IPv6 support |
The ASA now supports SNMP over IPv6, including communicating with SNMP servers over IPv6, allowing the execution of queries and traps over IPv6, and supporting IPv6 addresses for existing MIBs. We added the following new SNMP IPv6 MIB objects as described in RFC 8096.
New or modified command: snmp-server host
|
||
|
Conditional Debugging to troubleshoot a single user session |
Conditional debugging feature now assists you to verify the logs of specific ASA VPN sessions based on the filter conditions that are set. Support for "any, any" for IPv4 and IPv6 subnets is provided. |
||
New Features in ASA 9.9(1)
Released: December 4, 2017
|
Feature |
Description |
|---|---|
|
Firewall Features |
|
|
Ethertype access control list changes |
EtherType access control lists now support Ethernet II IPX (EII IPX). In addition, new keywords are added to the DSAP keyword to support common DSAP values: BPDU (0x42), IPX (0xE0), Raw IPX (0xFF), and ISIS (0xFE). Consequently, existing EtherType access contol entries that use the BPDU or ISIS keywords will be converted automatically to use the DSAP specification, and rules for IPX will be converted to 3 rules (DSAP IPX, DSAP Raw IPX, and EII IPX). In addition, packet capture that uses IPX as an EtherType value has been deprecated, because IPX corresponds to 3 separate EtherTypes. New or modified command: access-list ethertype added the new keywords eii-ipx and dsap {bpdu | ipx | isis | raw-ipx} ; capture ethernet-type no longer supports the ipx keyword. |
|
VPN Features |
|
|
Distributed Site-to-Site VPN with clustering on the Firepower 9300 |
An ASA cluster on the Firepower 9300 supports Site-to-Site VPN in distributed mode. Distributed mode provides the ability to have many Site-to-Site IPsec IKEv2 VPN connections distributed across members of an ASA cluster, not just on the control unit (as in centralized mode). This significantly scales VPN support beyond Centralized VPN capabilities and provides high availability. Distributed S2S VPN runs on a cluster of up to two chassis, each containing up to three modules (six total cluster members), each module supporting up to 6K active sessions (12K total), for a maximum of approximately 36K active sessions (72K total). New or modified commands: cluster redistribute vpn-sessiondb, show cluster vpn-sessiondb, vpn mode , show cluster resource usage, show vpn-sessiondb , show connection detail, show crypto ikev2 |
|
High Availability and Scalability Features |
|
|
Active/Backup High Availability for ASAv on Microsoft Azure |
A stateless Active/Backup solution that allows for a failure of the active ASAv to trigger an automatic failover of the system to the backup ASAv in the Microsoft Azure public cloud. New or modified command: failover cloud
Also in 9.8(1.200). |
|
Improved chassis health check failure detection for the Firepower chassis |
You can now configure a lower holdtime for the chassis health check: 100 ms. The previous minimum was 300 ms. New or modified command: app-agent heartbeat interval |
|
Inter-site redundancy for clustering |
Inter-site redundancy ensures that a backup owner for a traffic flow will always be at the other site from the owner. This feature guards against site failure. New or modified commands: site-redundancy, show asp cluster counter change, show asp table cluster chash-table, show conn flag |
|
cluster remove unit command behavior matches no enable behavior |
The cluster remove unit command now removes a unit from the cluster until you manually reenable clustering or reload, similar to the no enable command. Previously, if you redeployed the bootstrap configuration from FXOS, clustering would be reenabled. Now, the disabled status persists even in the case of a bootstrap configuration redeployment. Reloading the ASA, however, will reenable clustering. New/Modified command: cluster remove unit |
|
Administrative, Monitoring, and Troubleshooting Features |
|
|
SSH version 1 has been deprecated |
SSH version 1 has been deprecated, and will be removed in a future release. The default setting has changed from both SSH v1 and v2 to just SSH v2. New/Modified commands: ssh version |
|
Enhanced packet tracer and packet capture capabilities |
The packet tracer has been enhanced with the following features:
The packet capture has been enhanced with the following features:
New or modified commands: cluster exec capture test trace include-decrypted, cluster exec capture test trace persist, cluster exec clear packet-tracer, cluster exec show packet-tracer id, cluster exec show packet-tracer origin, packet-tracer persist, packet-tracer transmit, packet-tracer decrypted, packet-tracer bypass-checks |
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, or install an ASA module that provides URL and other filtering services, such as ASA CX or ASA FirePOWER. 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.
Sending Traffic to Supported Hardware or Software Modules
Some ASA models allow you to configure software modules, or to insert hardware modules into the chassis, to provide advanced services. These modules provide additional traffic inspection and can block traffic based on your configured policies. You can send traffic to these modules to take advantage of these advanced services.
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