The ASA implementation of virtual private networking includes useful features that do not fit neatly into categories. This chapter describes some of these features.
Guidelines and Limitations
This section includes the guidelines and limitations for this feature.
Context Mode Guidelines
Supported in single and multiple context mode. In the appropriate release of the ASA General Operations CLI Configuration Guide, refer to Guidelines for Multiple Context Mode for the list of what is not supported in multiple context mode, and New Features which gives the breakdown of what was added throughout the releases.Firewall Mode Guidelines
Supported only in routed firewall mode. Transparent mode is not supported.
Network Address Translation (NAT)
For guidelines and information about NAT configuration, see the NAT for VPN section of the Cisco Secure Firewall ASA Series Firewall CLI Configuration Guide.
Configure IPsec to Bypass ACLs
To permit any packets that come from an IPsec tunnel without checking ACLs for the source and destination interfaces, enter the sysopt connection permit-vpn command in global configuration mode.
You might want to bypass interface ACLs for IPsec traffic if you use a separate VPN concentrator behind the ASA and want to maximize the ASA performance. Typically, you create an ACL that permits IPsec packets by using the access-list command and apply it to the source interface. Using an ACL allows you to specify the exact traffic you want to allow through the ASA.
The following example enables IPsec traffic through the ASA without checking ACLs:
hostname(config)# sysopt connection permit-vpn![CLI Book 3: Cisco Secure Firewall ASA VPN CLI Configuration Guide, 9.22 - General VPN Parameters [Cisco Secure Firewall ASA] (1)](https://i0.wp.com/www.cisco.com/content/dam/en/us/td/i/templates/note.gif "CLI Book 3: Cisco Secure Firewall ASA VPN CLI Configuration Guide, 9.22 - General VPN Parameters [Cisco Secure Firewall ASA] (1)") Note | Decrypted through-traffic is permitted from the client despite having an access group on the outside interface, which calls a deny ip any any ACL, while no sysopt connection permit-vpn is configured. Trying to control access to the protected network via site-to-site or remote access VPN using the no sysopt permit-vpn command in conjunction with an access control list (ACL) on the outside interface are not successful. sysopt connection permit-vpn will bypass ACLs (both in and out) on interface where crypto map for that interesting traffic is enabled, along with egress (out) ACLs of all other interfaces, but not the ingress (in) ACLs. In this situation, when management-access inside is enabled, the ACL is not applied, and users can still connect to the ASA using SSH. Traffic to hosts on the inside network is blocked correctly by the ACL, but decrypted through-traffic to the inside interface is not blocked. The ssh and http commands are of a higher priority than the ACLs. To deny SSH, Telnet, or ICMP traffic to the box from the VPN session, use ssh, telnet and icmp commands. |
Permitting Intra-Interface Traffic (Hairpinning)
The ASA includes a feature that lets a VPN client send IPsec-protected traffic to another VPN user by allowing that traffic in and out of the same interface. This is also called “hairpinning”, which can be thought of as VPN spokes (clients) connecting through a VPN hub (the ASA).
Hairpinning can also redirect incoming VPN traffic back out through the same interface as unencrypted traffic. This can be useful, for example, to a VPN client that does not have split tunneling, but needs to both access a VPN and browse the web.
The figure below shows VPN Client 1 sending secure IPsec traffic to VPN Client 2 while also sending unencrypted traffic to a public web server.
![CLI Book 3: Cisco Secure Firewall ASA VPN CLI Configuration Guide, 9.22 - General VPN Parameters [Cisco Secure Firewall ASA] (2)](https://i0.wp.com/www.cisco.com/content/dam/en/us/td/i/100001-200000/140001-150000/143001-144000/143170.ps/jcr:content/renditions/143170.jpg "CLI Book 3: Cisco Secure Firewall ASA VPN CLI Configuration Guide, 9.22 - General VPN Parameters [Cisco Secure Firewall ASA] (2)")
To configure this feature, use the same-security-traffic command in global configuration mode with its intra-interface argument.
The command syntax is same-security-traffic permit {inter-interface | intra-interface}.
The following example shows how to enable intra-interface traffic:
hostname(config)# same-security-traffic permit intra-interfacehostname(config)#Note | Use the same-security-traffic command with the inter-interface argument to permit communication between interfaces with the same security level. This feature is not specific to IPsec connections. For more information, see the “Configuring Interface Parameters” chapter of this guide. |
To use hairpinning, you must apply the proper NAT rules to the ASA interface, as described in NAT Considerations for Intra-Interface Traffic.
NAT Considerations for Intra-Interface Traffic
For the ASA to send unencrypted traffic back out through the interface, you must enable NAT for the interface so that publicly routable addresses replace your private IP addresses (unless you already use public IP addresses in your local IP address pool). The following example applies an interface PAT rule to traffic sourced from the client IP pool:
hostname(config)# ip local pool clientpool 192.168.0.10-192.168.0.100 hostname(config)# object network vpn_nathostname(config-network-object)# subnet 192.168.0.0 255.255.255.0hostname(config-network-object)# nat (outside,outside) interfaceWhen the ASA sends encrypted VPN traffic back out this same interface, however, NAT is optional. The VPN-to-VPN hairpinning works with or without NAT. To apply NAT to all outgoing traffic, implement only the commands above. To exempt the VPN-to-VPN traffic from NAT, add commands (to the example above) that implement NAT exemption for VPN-to-VPN traffic, such as:
hostname(config)# nat (outside,outside) source static vpn_nat vpn_nat destination static vpn_nat vpn_natFor more information on NAT rules, see the “Applying NAT” chapter of this guide.
Setting Maximum Active IPsec or SSL VPN Sessions
To limit VPN sessions to a lower value than the ASA allows, enter the vpn-sessiondb command in global configuration mode:
vpn-sessiondb {max-anyconnect-premium-or-essentials-limit <number> | max-other-vpn-limit <number>}
The max-anyconnect-premium-or-essentials-limit keyword specifies the maximum number of Secure Client sessions, from 1 to the maximum sessions allowed by the license.
Note | The correct licensing, term, tier, and user count is no longer determined with these commands. Refer to the Secure Client Ordering Guide: http://www.cisco.com/c/dam/en/us/products/collateral/security/anyconnect-og.pdf |
The max-other-vpn-limit keyword specifies the maximum number of VPN sessions other than the Secure Client sessions, from 1 to the maximum sessions allowed by the license. This includes the Cisco VPN client (IPsecIKEv1) and Lan-to-Lan VPN sessions.
This limit affects the calculated load percentage for VPN Load Balancing.
The following example shows how to set a maximum Anyconnect VPN session limit of 450:
hostname(config)# vpn-sessiondb max-anyconnect-premium-or-essentials-limit 450 hostname(config)#Use Client Update to Ensure Acceptable IPsec Client Revision Levels
Note | The information in this section applies to IPsec connections only. |
The client update feature lets administrators at a central location automatically notify VPN client users that it is time to update the VPN client software.
Remote users might be using outdated VPN software or hardware client versions. You can use the client-update command at any time to enable updating client revisions; specify the types and revision numbers of clients to which the update applies; provide a URL or IP address from which to get the update; and, in the case of Windows clients, optionally notify users that they should update their VPN client version. For Windows clients, you can provide a mechanism for users to accomplish that update. This command applies only to the IPsec remote-access tunnel-group type.
To perform a client update, enter the client-update command in either general configuration mode or tunnel-group ipsec-attributes configuration mode. If the client is already running a software version on the list of revision numbers, it does not need to update its software. If the client is not running a software version on the list, it should update. The following procedure explains how to perform a client update:
Procedure
| Step1 | In global configuration mode, enable client update by entering this command: | ||||
| Step2 | In global configuration mode, specify the parameters for the client update that you want to apply to all clients of a particular type. That is, specify the type of client, the URL or IP address from which to get the updated image, and the acceptable revision number or numbers for that client. You can specify up to four revision numbers, separated by commas. If the user’s client revision number matches one of the specified revision numbers, there is no need to update the client. This command specifies the client update values for all clients of the specified type across the entire ASA. Use this syntax: The available client types are win9X (includes Windows 95, Windows 98 and Windows ME platforms), winnt (includes Windows NT 4.0, Windows 2000 and Windows XP platforms), windows (includes all Windows based platforms). If the client is already running a software version on the list of revision numbers, it does not need to update its software. If the client is not running a software version on the list, it should update. You can specify up to three of these client update entries. The keyword windows covers all of the allowable Windows platforms. If you specify windows , do not specify the individual Windows client types.
Alternatively, you can configure client update just for individual tunnel groups, rather than for all clients of a particular type. (See Step3.)
| ||||
| Step3 | Define a set of client-update parameters for a particular ipsec-ra tunnel group. In tunnel-group ipsec-attributes mode, specify the tunnel group name and its type, the URL or IP address from which to get the updated image, and a revision number. If the user’s client’s revision number matches one of the specified revision numbers, there is no need to update the client, for example, for a Windows client enter this command: | ||||
| Step4 | (Optional) Send a notice to active users with outdated Windows clients that their client needs updating. For these users, a pop-up window appears, offering them the opportunity to launch a browser and download the updated software from the site that you specified in the URL. The only part of this message that you can configure is the URL. (See Step 2 or 3.) Users who are not active get a notification message the next time they log on. You can send this notice to all active clients on all tunnel groups, or you can send it to clients on a particular tunnel group. For example, to notify all active clients on all tunnel groups, enter the following command in privileged EXEC mode: If the user’s client’s revision number matches one of the specified revision numbers, there is no need to update the client, and no notification message is sent to the user. |
What to do next
Note | If you specify the client-update type as windows (specifying all Windows-based platforms) and later want to enter a client-update type of win9x or winnt for the same entity, you must first remove the windows client type with the no form of the command, then use new client-update commands to specify the new client types. |
Implement NAT-Assigned IP to Public IP Connection
In rare situations, you might want to use a VPN peer’s real IP 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 address if, for example, your inside servers and network security is based on the peer’s real IP address.
The ASA introduced a way to translate the VPN client’s assigned IP address on the internal/protected network to its public (source) IP address. This feature supports the scenario where the target servers/services on the internal network and network security policy require communication with the VPN client’s public/source IP instead of the assigned IP on the internal corporate network.
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.
Because of routing issues, we do not recommend using this feature unless you know you need it.
-
Only supports legacy (IKEv1) and Secure Clients.
-
Return traffic to the public IP addresses must be routed back to the ASA so the NAT policy and VPN policy can be applied.
-
Only supports IPv4 assigned and public addresses.
-
Multiple peers behind a NAT/PAT device are not supported.
-
Does not support load balancing (because of routing issue).
-
Does not support roaming.
Procedure
| Step1 | In global configuration mode, enter tunnel general. |
| Step2 | Use this syntax to enable the address translation: This command dynamically installs NAT policies of the assigned IP address to the public IP address of the source. The interface determines where to apply NAT. |
| Step3 | Use this syntax to disable the address translation: |
Displaying VPN NAT Policies
Address translation uses the underlying object NAT mechanisms; therefore, the VPN NAT policy displays just like manually configured object NAT policies. This example uses 95.1.226.4 as the assigned IP and 75.1.224.21 as the peer’s public IP:
hostname# show natAuto NAT Policies (Section 2)1 (outside) to (inside) source static _vpn_nat_95.1.226.4 75.1.224.21 translate_hits = 315, untranslate_hits = 315prompt# show nat detail
Auto NAT Policies (Section 2)1 (outside) to (inside) source static _vpn_nat_95.1.226.4 75.1.224.21 translate_hits = 315, untranslate_hits = 315 Source - Origin: 95.1.226.4/32, Translated: 75.1.224.21/32
Outside is the interface to which the Secure Client connects and inside is the interface specific to the new tunnel group.
Note | Since VPN NAT policies are dynamic and not added to the configuration, the VPN NAT object and NAT policy are hidden from the show run object and show run nat reports. |
Configure VPN Session Limits
You can run as many IPsec and SSL VPN sessions as your platform and ASA license supports. To view the licensing information including maximum sessions for your ASA, enter the show version command in global configuration mode and look for the licensing section. The following example shows the command and the licensing information from the output of this command; the other output is redacted for clarity.
hostname(config)# show version...Licensed features for this platform:Maximum Physical Interfaces : Unlimited perpetualMaximum VLANs : 500 perpetualInside Hosts : Unlimited perpetualFailover : Active/Active perpetualEncryption-DES : Enabled perpetualEncryption-3DES-AES : Enabled perpetualSecurity Contexts : 100 perpetualCarrier : Enabled perpetualAnyConnect Premium Peers : 5000 perpetualAnyConnect Essentials : 5000 perpetualOther VPN Peers : 5000 perpetualTotal VPN Peers : 5000 perpetualAnyConnect for Mobile : Enabled perpetualAnyConnect for Cisco VPN Phone : Enabled perpetualAdvanced Endpoint Assessment : Enabled perpetualShared License : Disabled perpetualTotal TLS Proxy Sessions : 3000 perpetualBotnet Traffic Filter : Disabled perpetualIPS Module : Disabled perpetualCluster : Enabled perpetualCluster Members : 2 perpetualThis platform has an ASA5555 VPN Premium license.Show License Resource Allocation
Use the following command to show the resource allocation:
asa2(config)# sh resource allocationResourceTotal% of AvailConns[rate]100(U)0.00%Inspects[rate]unlimitedSyslogs[rate]unlimitedConnsunlimitedHostsunlimitedIPsecunlimitedMac-addressesunlimitedASDM105.00%SSH1010.00%Telnet1010.0%XlatesunlimitedAnyConnect100010%AnyConnectBurst2002%OtherVPN200020%OtherVPNBurst100010%Show License Resource Usage
Use the following command to show resource usage:
Note | You can also use the sh resource usage system controller all 0 command to show system level usage with the limit as the platform limit. |
Limit VPN Sessions
To limit AnyConnect VPN sessions (either IPsec/IKEv2 or SSL) to a lower value than the ASA allows, use the vpn-sessiondb max-anyconnect-premium-or-essentials-limit command in global configuration mode. To remove the session limit, use the no version of this command.
If the ASA license allows 500 SSL VPN sessions, and you want to limit the number of AnyConnect VPN sessions to 250, enter the following command:
hostname(config)# vpn-sessiondb max-anyconnect-premium-or-essentials-limit 250hostname(config)#To remove the session limit, use the no version of this command.:
hostname(config)# no vpn-sessiondb max-anyconnect-premium-or-essentials-limit 250hostname(config)#Using an Identify Certificate When Negotiating
The ASA needs to use an identity certificate when negotiating the IKEv2 tunnel with Secure Clients. For ikev2 remote access trustpoint configuration, use the following commands
crypto ikev2 remote-access trustpoint <name> [line<number>]Using this command allows the Secure Client to support group selection for the end user. You can configure two trustpoints at the same time: two RSA, two ECDSA, or one of each. The ASA scans the configured trustpoint list and chooses the first one that the client supports. If ECDSA is preferred, you should configure that trustpoint before the RSA trustpoint.
The line number option specifies where in the line number you want the trustpoint inserted. Typically, this option is used to insert a trustpoint at the top without removing and re-adding the other line. If a line is not specified, the ASA adds the trustpoint at the end of the list.
If you try to add a trustpoint that already exists, you receive an error. If you use the no crypto ikev2 remote-access trustpoint command without specifying which trustpoint name to remove, all trustpoint configuration is removed.
Configure the Pool of Cryptographic Cores
You can change the allocation of cryptographic cores on Symmetric Multi-Processing (SMP) platforms to increase the throughput of Secure Client TLS/DTLS traffic. These changes can accelerate the SSL VPN datapath and provide customer-visible performance gains in Secure Client, smart tunnels, and port forwarding. These steps describe configuring the pool of cryptographic cores in either single or multiple context mode.
Procedure
Specify how to allocate crypto accelerator processors:
crypto engine accelerator-bias
-
balanced—Equally distributes cryptography hardware resources (Admin/SSL and IPsec cores).
-
ipsec—Allocates cryptography hardware resources to favor IPsec (includes SRTP encrypted voice traffic).
-
ssl—Allocates cryptography hardware resources to favor Admin/SSL. Use this bias when you support SSL-based Secure Client remote access VPN sessions.
Example:
hostname(config)# crypto engine accelerator-bias ssl
Configure Dynamic Split Tunneling
With dynamic split tunneling, you can dynamically provision split exclude tunneling after tunnel establishment based on the host DNS domain name. Dynamic split tunneling is configured by creating a custom attribute and adding it to a group policy.
Before you begin
To use this feature, you must have AnyConnect release 4.5 (or later). Refer to About Dynamic Split Tunneling for further explanation.
Procedure
| Step1 | Define the custom attribute type in the WebVPN context with the following command: |
| Step2 | Define the custom attribute names for each cloud/web service that needs access by the client outside the VPN tunnel. For example, add Google_domains to represent a list of DNS domain names pertaining to Google web services. The attribute value contains the list of domain names to exclude from the VPN tunnel and must be comma-separated-values (CSV) format as the following: |
| Step3 | Attach the previously defined custom attribute to a certain policy group with the following command, executed in the group-policy attributes context: |
What to do next
Configure the Management VPN Tunnel
A management VPN tunnel ensures connectivity to the corporate network whenever the client system is powered up, not just when a VPN connection is established by the end user. You can perform patch management on out-of-the-office endpoints, especially devices that are infrequently connected by the user, via VPN, to the office network. Endpoint OS login scripts which require corporate network connectivity will also benefit from this feature.
The management VPN tunnel is meant to be transparent to the end user; therefore, network traffic initiated by user applications is not impacted, by default, but instead directed outside the management VPN tunnel.
If a user complains of slow logins, it may be an indication that the management tunnel was not configured appropriately. Refer to the Cisco Secure Client Administration Guide for additional requirements, incompatibilities, limitations, and troubleshooting of management VPN tunnel.
Before you begin
Requires AnyConnect release 4.7 (or later)
Procedure
| Step1 | Add the uploaded profile (profileMgmt) to the group policy (MgmtTunGrpPolicy) mapped to the tunnel group used by the management tunnel connection: To indicate the profile is the AnyConnect Management VPN Profile, include type vpn-mgmt on the anyconnect profiles command. A regular AnyConnect VPN profile is type user. |
| Step2 | To deploy the management VPN profile through user tunnel connection, add the uploaded profile (profileMgmt) to the group policy (DfltGrpPolicy) mapped to the tunnel group used by the user tunnel connection: |
Viewing Active VPN Sessions
The following topics explain how to view VPN session information.
Viewing Active Secure Client Sessions by IP Address Type
To view active Secure Client sessions using the command line interface, enter the show vpn-sessiondb anyconnect filter p-ipversion or showvpn-sessiondb anyconnect filter a-ipversion command in privileged EXEC mode.
-
Display the active Secure Client sessions which are filtered by the endpoint’s public IPv4 or IPv6 address. The public address is the address assigned to the endpoint by the enterprise.
show vpn-sessiondb anyconnect filter p-ipversion {v4 | v6} -
Display the active Secure Client sessions which are filtered by the endpoint’s assigned IPv4 or IPv6 address. The assigned address is the address assigned to the Secure Client by the ASA.
show vpn-sessiondb anyconnect filter a-ipversion {v4 | v6}
Example Output from show vpn-sessiondb anyconnect filter p-ipversion [v4 | v6] command
hostname(config)# show vpn-sessiondb anyconnect filter p-ipversion v4Session Type: AnyConnectUsername : user1 Index : 40Assigned IP : 192.168.17.10 Public IP : 198.51.100.1Protocol : AnyConnect-Parent SSL-TunnelLicense : AnyConnect PremiumEncryption : AnyConnect-Parent: (1)none SSL-Tunnel: (1)RC4Hashing : AnyConnect-Parent: (1)none SSL-Tunnel: (1)SHA1Bytes Tx : 10570 Bytes Rx : 8085Group Policy : GroupPolicy_SSLACCLIENTTunnel Group : SSLACCLIENTLogin Time : 15:17:12 UTC Mon Oct 22 2012Duration : 0h:00m:09sInactivity : 0h:00m:00sNAC Result : UnknownVLAN Mapping : N/A VLAN : noneOutput from show vpn-sessiondb anyconnect filter a-ipversion [v4 | v6] command
hostname(config)# show vpn-sessiondb anyconnect filter a-ipversion v6Session Type: AnyConnectUsername : user1 Index : 45Assigned IP : 192.168.17.10Public IP : 2001:DB8:8:1:90eb:3fe5:9eea:fb29Assigned IPv6: 2001:DB8:9:1::24Protocol : AnyConnect-Parent SSL-TunnelLicense : AnyConnect PremiumEncryption : AnyConnect-Parent: (1)none SSL-Tunnel: (1)RC4Hashing : AnyConnect-Parent: (1)none SSL-Tunnel: (1)SHA1Bytes Tx : 10662 Bytes Rx : 17248Group Policy : GroupPolicy_SSL_IPv6 Tunnel Group : SSL_IPv6Login Time : 17:42:42 UTC Mon Oct 22 2012Duration : 0h:00m:33sInactivity : 0h:00m:00sNAC Result : UnknownVLAN Mapping : N/A VLAN : noneViewing Active LAN to LAN VPN Sessions by IP Address Type
To view active clientless SSL VPN sessions using the command line interface, enter the show vpn-sessiondb l2l filter ipversion command in privileged EXEC mode.
This command shows active lan to lan VPN sessions filtered by the connection’s public IPv4 or IPv6 address.
The public address is the address assigned to the endpoint by the enterprise.
show vpn-sessiondb l2l filter ipversion {v4 | v6} About ISE Policy Enforcement
The Cisco Identity Services Engine (ISE) is a security policy management and control platform. It automates and simplifies access control and security compliance for wired, wireless, and VPN connectivity. Cisco ISE is primarily used to provide secure access and guest access, support bring your own device (BYOD) initiatives, and enforce usage policies in conjunction with Cisco TrustSec.
The ISE Change of Authorization (CoA) feature provides a mechanism to change the attributes of an authentication, authorization, and accounting (AAA) session after it is established. When a policy changes for a user or user group in AAA, CoA packets can be sent directly to the ASA from the ISE to reinitialize authentication and apply the new policy. An Inline Posture Enforcement Point (IPEP) is not required to apply access control lists (ACLs) for each VPN session established with the ASA.
ISE policy enforcement is supported on the following VPN clients:
-
IPSec
-
Secure Client
-
L2TP/IPSec
Note | Some policy elements such as Dynamic ACL (dACL) and Security Group Tag (SGT) are supported, whereas policy elements such as VLAN assignment and IP address assignment are not supported. |
The system flow is as follows:
-
An end user requests a VPN connection.
-
The ASA authenticates the user to the ISE and receives a user ACL that provides limited access to the network.
-
An accounting start message is sent to the ISE to register the session.
-
Posture assessment occurs directly between the NAC agent and the ISE. This process is transparent to the ASA.
-
The ISE sends a policy update to the ASA via a CoA “policy push.” This identifies a new user ACL that provides increased network access privileges.
![CLI Book 3: Cisco Secure Firewall ASA VPN CLI Configuration Guide, 9.22 - General VPN Parameters [Cisco Secure Firewall ASA] (10)](data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw== "CLI Book 3: Cisco Secure Firewall ASA VPN CLI Configuration Guide, 9.22 - General VPN Parameters [Cisco Secure Firewall ASA] (10)")
Note
Additional policy evaluations may occur during the lifetime of the connection, transparent to the ASA, via subsequent CoA updates.
Configure RADIUS Server Groups for ISE Policy Enforcement
To enable ISE policy assessment and enforcement, configure a RADIUS AAA server group for the ISE servers and add the servers to the group. When you configure the tunnel group for the VPN, you specify this server group for AAA services in the group.
Procedure
| Step1 | Create the RADIUS AAA server group. aaa-server group_name protocol radius |
| Step2 | Enable the RADIUS dynamic authorization (CoA) services for the AAA server group. dynamic-authorization [port number] Specifying a port is optional. The default is 1700, the range is 1024 to 65535. When you use the server group in a VPN tunnel, the RADIUS server group will be registered for CoA notification and the ASA will listen to the port for the CoA policy updates from ISE |
| Step3 | If you do not want to use ISE for authentication, enable authorize-only mode for the RADIUS server group. authorize-only This indicates that when this server group is used for authorization, the RADIUS Access Request message will be built as an “Authorize Only” request as opposed to the configured password methods defined for the AAA server. If you do configure a common password using radius-common-pw command for the RADIUS server, it will be ignored. For example, you would use authorize-only mode if you want to use certificates for authentication rather than this server group. You would still use this server group for authorization and accounting in the VPN tunnel. |
| Step4 | Enable the periodic generation of RADIUS interim-accounting-update messages. interim-accounting-update [periodic [hours]] ISE maintains a directory of active sessions based on the accounting records that it receives from NAS devices like the ASA. However, if ISE does not receive any indication that the session is still active (accounting message or posture transactions) for a period of 5 days, it will remove the session record from its database. To ensure that long-lived VPN connections are not removed, configure the group to send periodic interim-accounting-update messages to ISE for all active sessions.
|
| Step5 | (Optional.) Merge a downloadable ACL with the ACL received in the Cisco AV pair from a RADIUS packet. merge-dacl {before-avpair | after-avpair} This option applies only to VPN connections. For VPN users, ACLs can be in the form of Cisco AV pair ACLs, downloadable ACLs, and an ACL that is configured on the ASA. This option determines whether or not the downloadable ACL and the AV pair ACL are merged, and does not apply to any ACLs configured on the ASA. The default setting is no merge dacl , which specifies that downloadable ACLs will not be merged with Cisco AV pair ACLs. If both an AV pair and a downloadable ACL are received, the AV pair has priority and is used. The before-avpair option specifies that the downloadable ACL entries should be placed before the Cisco AV pair entries. The after-avpair option specifies that the downloadable ACL entries should be placed after the Cisco AV pair entries. |
| Step6 | (Optional.) Specify the maximum number of requests sent to a RADIUS server in the group before trying the next server. max-failed-attempts number The range is from 1 and 5. The default is 3. If you configured a fallback method using the local database (for management access only), and all the servers in the group fail to respond, then the group is considered to be unresponsive, and the fallback method is tried. The server group remains marked as unresponsive for a period of 10 minutes (by default), so that additional AAA requests within that period do not attempt to contact the server group, and the fallback method is used immediately. To change the unresponsive period from the default, see the reactivation-mode command in the next step. If you do not have a fallback method, the ASA continues to retry the servers in the group. |
| Step7 | (Optional.) Specify the method (reactivation policy) by which failed servers in a group are reactivated. reactivation-mode {depletion [deadtime minutes] | timed} Where:
|
| Step8 | (Optional.) Send accounting messages to all servers in the group. accounting-mode simultaneous To restore the default of sending messages only to the active server, enter the accounting-mode single command. |
| Step9 | Add the ISE RADIUS servers to the group. aaa-server group_name [(interface_name)] host {server_ip | name} [key] Where:
You can add more than one server to the group. |
Example Configurations for ISE Policy Enforcement
Configure VPN Tunnel for ISE Dynamic Authentication with Passwords
The following example shows how to configure an ISE server group for dynamic authorization (CoA) updates and hourly periodic accounting. Included is the tunnel group configuration that configures password authentication with ISE.
ciscoasa(config)# aaa-server ise protocol radiusciscoasa(config-aaa-server-group)# interim-accounting-update periodic 1ciscoasa(config-aaa-server-group)# dynamic-authorizationciscoasa(config-aaa-server-group)# exitciscoasa(config)# aaa-server ise (inside) host 10.1.1.3ciscoasa(config-aaa-server-host)# key sharedsecretciscoasa(config-aaa-server-host)# exitciscoasa(config)# tunnel-group aaa-coa general-attributesciscoasa(config-tunnel-general)# address-pool vpnciscoasa(config-tunnel-general)# authentication-server-group iseciscoasa(config-tunnel-general)# accounting-server-group iseciscoasa(config-tunnel-general)# exitConfigure VPN Tunnel for ISE Authorization-Only
The following example shows how to configure a tunnel group for local certificate validation and authorization with ISE. Include the authorize-only command in the server group configuration, because the server group will not be used for authentication.
ciscoasa(config)# aaa-server ise protocol radiusciscoasa(config-aaa-server-group)# authorize-onlyciscoasa(config-aaa-server-group)# interim-accounting-update periodic 1ciscoasa(config-aaa-server-group)# dynamic-authorizationciscoasa(config-aaa-server-group)# exitciscoasa(config)# aaa-server ise (inside) host 10.1.1.3ciscoasa(config-aaa-server-host)# key sharedsecretciscoasa(config-aaa-server-host)# exitciscoasa(config)# tunnel-group aaa-coa general-attributesciscoasa(config-tunnel-general)# address-pool vpnciscoasa(config-tunnel-general)# authentication certificateciscoasa(config-tunnel-general)# authorization-server-group iseciscoasa(config-tunnel-general)# accounting-server-group iseciscoasa(config-tunnel-general)# exitTroubleshooting Policy Enforcement
The following commands can be used for debugging.
To trace CoA activity:
debug radius dynamic-authorizationTo trace redirect URL functionality:
debug aaa url-redirectTo view NP classification rules corresponding to URL redirect functionality:
show asp table classify domain url-redirectConfigure Advanced SSL Settings
The ASA uses the Secure Sockets Layer (SSL) protocol and the Transport Layer Security (TLS) to support secure message transmission for ASDM, Clientless SSL VPN, VPN, and browser-based sessions. The ASA supports the SSLv3, TLSv1, TLv1.1, TLSv1.2, and TLSv1.3 protocols for SSL-based VPN and management connections. In addition, DTLS is used for the AnyConnect VPN module of Cisco Secure Client connections.
The following ciphers are supported as noted:
| Cipher | TLSv1.1 / DTLS V1 | TLSV1.2 / DTLSV 1.2 | TLSv1.3 |
|---|---|---|---|
| TLS_AES_128_GCM_SHA256 | no | no | yes |
| TLS_CHACHA20_POLY1305_SHA256 | no | no | yes |
| TLS_AES_256_GCM_SHA384 | no | no | yes |
| AES128-GCM-SHA256 | no | yes | no |
| AES128-SHA | yes | yes | no |
| AES128-SHA256 | no | yes | no |
| AES256-GCM-SHA384 | no | yes | no |
| AES256-SHA | yes | yes | no |
| AES256-SHA256 | no | yes | no |
| DERS-CBC-SHA | no | no | no |
| DES-CBC-SHA | yes | yes | no |
| DHE-RSA-AES128-GCM-SHA256 | no | yes | no |
| DHE-RSA-AES128-SHA | yes | yes | no |
| DHE-RSA-AES128-SHA256 | no | yes | no |
| DHE-RSA-AES256-GCM-SHA384 | no | l | no |
| DHE-RSA-AES256-SHA | yes | yes | no |
| ECDHE-ECDSA-AES128-GCM-SHA256 | no | yes | no |
| ECDHE-ECDSA-AES128-SHA256 | no | yes | no |
| ECDHE-ECDSA-AES256-GCM-SHA384 | no | yes | no |
| ECDHE-ECDSA-AES256-SHA384 | no | yes | no |
| ECDHE-RSA-AES128-GCM-SHA256 | yes | yes | no |
| ECDHE-RSA-AES128-SHA256 | no | yes | no |
| ECDHE-RSA-AES256-GCM-SHA384 | no | yes | no |
| ECDHE-RSA-AES256-SHA384 | no | yes | no |
| NULL-SHA | no | no | no |
| RC4-MD5 | no | no | no |
| RC4-SHA | no | no | no |
Note | For Release 9.4(1), all SSLv3 keywords have been removed from the ASA configuration, and SSLv3 support has been removed from the ASA. If you have SSLv3 enabled, a boot-time error will appear from the command with the SSLv3 option. The ASA will then revert to the default use of TLSv1. The Citrix mobile receiver may not support TLS 1.1/1.2 protocols; see https://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/citrix-receiver-feature-matrix.pdf for compatibility |
To specify the minimum protocol version for which the ASA will negotiate SSL/TLS and DTLS connections, perform the following steps:
Procedure
| Step1 | Set the minimum protocol version for which the ASA will negotiate a connection. ssl server-version [ tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3] [ dtlsv1 | dtlsv1.2] Where:
Example: | ||
| Step2 | Specify the maximum version of SSL/TLS protocol that ASA uses when acting as a server. ssl server-max-version [ tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3] If the server-max-version is configured as TLSV1.2, you won't be able to configure TLSV1.3 as the server-version. | ||
| Step3 | Specify the SSL/TLS protocol version that the ASA uses when acting as a client. ssl client-version [ tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3] Where:
DTLS is not available for SSL client role. Example: | ||
| Step4 | Specify the maximum version of SSL/TLS protocol that ASA uses when acting as a client. ssl client-max-version [ tlsv1 | tlsv1.1 | tlsv1.2 | tlsv1.3] If the client-max-version is configured as TLSV1.2, you won't be able to configure TLSV1.3 as the client-version. | ||
| Step5 | Specify the encryption algorithms for the SSL, DTLS, and TLS protocols. ssl cipher version [ level | custom string] Where:
The recommended setting is medium . Using high may limit connectivity. Using custom may limit functionality if there are only a few ciphers configured. Restricting the default custom value limits outbound connectivity, including clustering. The ASA specifies the order of priority for supported ciphers. See the command reference for more information. This command replaces the ssl encryption command, which has been deprecated starting with Version 9.3(2). | ||
| Step6 | Allow multiple trustpoints on a single interface. ssl trust-point name [[ interface vpnlb-ip ] | [ domain domain-name] The name argument specifies the name of the trustpoint. The interface argument specifies the name of the interface on which a trustpoint is configured. The vpnlb-ip keyword applies only to interfaces and associates this trustpoint with the VPN load-balancing cluster IP address on this interface. The domaindomain-name keyword-argument pair specifies a trustpoint that is associated with a particular domain name that is used to access the interface. You may configure a maximum of 16 trustpoints per interface. If you do not specify an interface or domain, this command creates the fallback trustpoint for all interfaces that do not have a trustpoint configured. If you enter the ssl trustpoint ? command, the available configured trustpoints appear. If you enter the ssl trust-point name ? command (for example, ssl trust-point mysslcert ? ), the available configured interfaces for the trustpoint-SSL certificate association appear. Observe these guidelines when using this command:
| ||
| Step7 | Specify the DH group to be used with DHE-RSA ciphers that are used by TLS. The group14 and 15 keyword configures DH group 14 (2048-bit modulus, 224-bit prime order subgroup). Group 14 is not compatible with Java 7. All groups are compatible with Java 8. Groups 14 is FIPS-compliant. The default value is ssl dh-group group14 . | ||
| Step8 | Specify the group to be used with ECDHE-ECDSA ciphers that are used by TLS. The group19 keyword configures group 19 (256-bit EC). The group20 keyword configures group 20 (384-bit EC). The group21 keyword configures group 21 (521-bit EC). The default value is ssl ecdh-group group19 .
|
What to do next
You can use the use the following commands to view the TLS/DTLS configuration:
-
show run ssl if it is not the default TLS/DTLS version.
-
show run ssl all if it is the default TLS/DTLS version.
Rate Limit for Preauthenticated SSL Connections
Preauthenticated SSL connections are secure connections that are established before a user or device has completed the authentication process. ASA can receive multiple preauthenticated SSL connections that can increase the memory usage of the device, prevent new SSL connections, make the device unresponsive, and impact performance.
ASA can rate-limit these preauthenticated SSL connections. This limit is calculated as 3 times the VPN connection limit of the device. This feature is enabled by default and is supported only on ASA virtual. For example, for an ASAv10, the VPN connection limit is 250. The preauthentication limit of SSL connections is 3 x 250 = 750.
For a device, when the preauthenticated connection limit exceeds, no new SSL connections are allowed. However, this restriction is not valid for management connections. The device allows new SSL connections only after the preauthenticated SSL connections count becomes zero.
Supported Devices
-
ASAv5
-
ASAv10
-
ASAv30
-
ASAv50
-
ASAv100
Syslog
The device generates syslog 725025 when it reaches the rate-limit threshold for the number of preauthenticated SSL connections. This syslog is generated when the number of preauthenticated SSL connections is high (90% of the limit) and when it is low (70% of the limit). The syslog is rate-limited to one syslog every 10 seconds.
Counters
Three new counters provide information about the rate-limited preauthenticated SSL connections:
-
SOCK_PRE_AUTH_COUNT_EXCEEDED: An increment by one indicates that the number of simultaneous preauthenticated SSL connections has exceeded the VPN limit. New connection attempts are blocked until the SOCK_PRE_AUTH_COUNT counter is 0.
-
SOCK_COUNT_RATE_LIMIT: Indicates the connections that the ASA has reset after exceeding the rate limit.
-
SOCK_PRE_AUTH_COUNT: Number of concurrent preauthentication connections at any given time.
Use the show counters command to view the details of these counters.
Debug Commands
As debugging output is assigned high priority in the CPU process, it can render the system unusable. We recommend that you use debug commands only during troubleshooting sessions with Cisco TAC.
You can use the following debug commands for this feature:
-
debug menu ctm 1205: Disable or re-enable the feature.
-
debug menu ctm 1206: Verify the current status of the feature.
vASA# debug menu ctm 1205 Disabling SSL pre-auth connection rate monitoringvASA# debug menu ctm 1206 SSL PRE-AUTH connection rate monitoring is Disabled Persistent IPsec Tunneled Flows
In networks running a version of ASA software prior to Release 8.0.4, existing IPsec LAN-to-LAN or Remote-Access TCP traffic flows going through an IPSec tunnel are dropped when the tunnel drops. The flows are recreated as needed when and if the tunnel comes back up. This policy works well from the resource-management and security standpoints. However, there are cases in which such behavior introduces issues for users, particularly for those migrating from PIX to ASA-only environments and for legacy TCP applications that do not restart easily or in networks that include gateways that tend to drop tunnels frequently.(See CSCsj40681 and CSCsi47630 for details.)
The persistent IPsec tunneled flows feature addresses this issue. With this feature enabled, the ASA preserves and resumes stateful (TCP) tunneled flows. All other flows are dropped when the tunnel drops and must reestablish when a new tunnel comes up.
Note | This feature supports IPsec LAN-to-LAN tunnels and IPsec Remote-Access tunnels running in Network-Extension Mode. It does not support IPsec or AnyConnect/SSL VPN remote access tunnels. |
The following example shows how the persistent IPsec tunneled flows feature works.
![CLI Book 3: Cisco Secure Firewall ASA VPN CLI Configuration Guide, 9.22 - General VPN Parameters [Cisco Secure Firewall ASA] (13)](https://i0.wp.com/www.cisco.com/content/dam/en/us/td/i/200001-300000/240001-250000/242001-243000/242687.eps/jcr:content/renditions/242687.jpg "CLI Book 3: Cisco Secure Firewall ASA VPN CLI Configuration Guide, 9.22 - General VPN Parameters [Cisco Secure Firewall ASA] (13)")
In this example the BXB and RTP networks are connected through a secure LAN-to-LAN tunnel by a pair of security appliances. A PC in the BXB network is executing an FTP transfer from a server in the RTP network through the secure tunnel. In this scenario, assume that for some reason the tunnel drops after the PC has logged into the server and started the transfer. Although the tunnel is be reestablished since the data is still attempting to flow, the FTP transfer will not complete. The user must terminate the transfer and start over by logging back into the server. However, if persistent IPsec tunnel flows is enabled, as long as the tunnel is recreated within the timeout interval, the data continues to flow successfully through the new tunnel because the security appliances retain the history (state information) for this flow.
Scenario
The following sections describe the data flow situations for a dropped and recovered tunnel, first with the persistent IPsec tunneled flows feature disabled, then with the feature enabled. In both of these cases, see the preceding figure for an illustration of the network. In this illustration:
-
Flow B-C defines the tunnel and carries the encrypted ESP data.
-
Flow A-D is the TCP connection for the FTP transfer and traverses the tunnel defined by flow B-C. This flow also contains state information used by the firewall to inspect the TCP/FTP flow. The state information is vital and is constantly updated by the firewall as the transfer progresses.
Note
The reverse flows in each direction are omitted for simplicity.
Disabled Persistent IPsec Tunneled Flows
When the LAN-2-LAN tunnel drops, both flow A-D and flow B-C and any state information belonging to them are deleted. Subsequently, the tunnel is reestablished, and flow B-C is recreated and is able to resume carrying tunneled data. But the TCP/FTP flow A-D runs into trouble. Because the state information describing the flow up to this point in the FTP transfer has been deleted, the stateful firewall blocks the in-flight FTP data and rejects the flow A-D creation. Having lost the history of this flow ever existing, the firewall treats the FTP transfer as stray TCP packets and drops them. This is the default behavior.
Enabled Persistent IPsec Tunneled Flows
With the persistent IPsec tunneled flows feature enabled, as long as the tunnel is recreated within the timeout window, data continues flowing successfully because the ASA still has access to the state information in flow A-D.
With this feature enabled, the ASA treats the flows independently. This means that flow A-D is not deleted when the tunnel defined by flow B-C is dropped. The ASA preserves and resumes stateful (TCP) tunneled flows. All other flows are dropped and must reestablish on the new tunnel. This does not weaken the security policy for tunneled flows, because the ASA drops any packets arriving on flow A-D while the tunnel is down.
Tunneled TCP flows are not dropped, so they rely on the TCP timeout for cleanup. However, if the timeout is disabled for a particular tunneled flow, that flow remains in the system until being cleared manually or by other means (for example, by a TCP RST from the peer).
Configure Persistent IPsec Tunneled Flows Using CLI
Troubleshooting Persistent IPsec Tunneled Flows
Both the show asp table and the show conn commands can be useful in troubleshooting issues with persistent IPsec tunneled flows.
Is the Persistent IPsec Tunneled Flows Feature Enabled?
To see whether a particular tunnel has this feature enabled, look at the VPN context associated with the tunnel using the show asp table command. The show asp table vpn-context command displays a “+PRESERVE” flag for each context that maintains stateful flows after the tunnel drops, as shown in the following example (bolding added for legibility):
hostname(config)# show asp table vpn-contextVPN CTX=0x0005FF54, Ptr=0x6DE62DA0, DECR+ESP+PRESERVE, UP, pk=0000000000, rk=0000000000, gc=0VPN CTX=0x0005B234, Ptr=0x6DE635E0, ENCR+ESP+PRESERVE, UP, pk=0000000000, rk=0000000000, gc=0---------------------------------------------------------------------------hostname(config)# show asp table vpn-context detailVPN CTX = 0x0005FF54Peer IP = ASA_PrivatePointer = 0x6DE62DA0State = UPFlags = DECR+ESP+PRESERVESA = 0x001659BFSPI = 0xB326496CGroup = 0Pkts = 0Bad Pkts = 0Bad SPI = 0Spoof = 0Bad Crypto = 0Rekey Pkt = 0Rekey Call = 0VPN CTX = 0x0005B234Peer IP = ASA_PrivatePointer = 0x6DE635E0State = UPFlags = ENCR+ESP+PRESERVESA = 0x0017988DSPI = 0x9AA50F43Group = 0Pkts = 0Bad Pkts = 0Bad SPI = 0Spoof = 0Bad Crypto = 0Rekey Pkt = 0Rekey Call = 0hostname(config)#Configuration and RestrictionsThis configuration option is subject to the same CLI configuration restrictions as other sysopt VPN CLI.Locating Orphaned Flows
If a LAN-to-LAN/Network-Extension-Mode tunnel drops and does not recover before the timeout, there might be a number of orphaned tunnel flows. These flows are not torn down as a result of the tunnel going down, but all the data attempting to flow through them is dropped. To see these flows, use the show conn command, as in the following examples (bolding added for emphasis and to show user input):
asa2(config)# show conn detail9 in use, 14 most usedFlags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN, B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump, E - outside back connection, F - outside FIN, f - inside FIN, G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data, i - incomplete, J - GTP, j - GTP data, K - GTP t3-response k - Skinny media, M - SMTP data, m - SIP media, n - GUP O - outbound data, P - inside back connection, p - Phone-proxy TFTP connection, q - SQL*Net data, R - outside acknowledged FIN, R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN, s - awaiting outside SYN, T - SIP, t - SIP transient, U - up, V - VPN orphan, W - WAAS, X - inspected by service moduleThe following example shows sample output from the show conn command when an orphan flow exists, as indicated by the V flag:
hostname# show conn16 in use, 19 most usedTCP out 192.168.110.251:7393 in 192.168.150.252:21 idle 0:00:00 bytes 1048 flags UOVBTCP out 192.168.110.251:21137 in 192.168.150.252:21 idle bytes 1048 flags UIOBTo limit the report to those connections that have orphan flows, add the vpn_orphan option to the show conn state command, as in the following example:
hostname# show conn state vpn_orphan14 in use, 19 most usedTCP out 192.168.110.251:7393 in 192.168.150.252:5013 idle 0:00:00 bytes 2841019 flags UOVBTroubleshooting Using Crypto Archives
About Crypto Archives
Crypto issues are difficult to triage. Crypto archives help you to troubleshoot these issues. A crypto archive contains crypto session information about the crypto request, peer information, the component that sent the crypto request, and the timed-out crypto session information. ASA does not save keys and initialization vectors (IVs) for the session. For SSL and IPsec, you can also view the following information:
-
For SSL: Session SSL version, source, destination IP addresses, and ports.
-
For IPsec: IPsec security association information.
A ring can hold 2000 crypto command entries. ASA pushes the crypto command in one of the rings and pulls out the result after completing the crypto request. Crypto archive files now have the timed-out crypto request's ring and entry index. The ring and its entry index help in troubleshooting problematic crypto commands.
The crypto archive has two formats: a text file and a binary file. You can use the debug menu ctm 103 command to decode the binary file.
For example:
ASA# debug menu ctm 103 crypto_eng0_arch_4.bin[Nitrox V Archive Header v1.0 Info]ASA Image Version: PIX (9.20) #0: Tue Mar 29 16:20:30 GMT 2022...SE SSL microcode: CNN5x-MC-SE-SSL-0011AE microcode: CNN5x-MC-AE-MAIN-0002Crypto Engine 0Crash type: SE Ring Timeout...Core Soft Resets: 11...Timeout Ring (SE): 12Timeout Entry: 642SE TIMEOUT:Core SE 6 Touts: 2Core SE 8 Touts: 2Core SE 12 Touts: 4Core SE 32 Touts: 2Core SE 37 Touts: 1.....[Timeout Session Info]Active: TRUESync: FALSECallback: TRUESaved Callback: FALSECommands in progress: 1Engine : hardwareDevice : n5 (Nitrox V)Session : sslPriority: normalNP VPN context handle : 0x00000000Flag : 0vcid : 0Block size : 2050async cb ring index: 0tls offload rsa: FALSESession context:SSL Version : dtls1.2SSL Context Type : handshakeEncryption Mode : gcmAuth Algorithm : nullHash Algorithm : noneKey Size : 32SSL V : dtls1.2Source IP : 82.1.2.2Source Port : 51915Dest IP : 82.29.155.32Dest Port : 443In the above example, the highlighted information shows the timeout ring, the crash time (timeout entry), and SSL session information.
Supported Devices for Crypto Archives
The following devices with Nitrox V crypto accelerator support crypto archives:
-
Cisco Firepower 3105, 3110, 3120, 3130, 3140
-
Cisco Firepower 4112, 4115, 4125, 4145
-
Cisco Firepower 9300 SM-40, SM-48 and SM-56
Using SSL Counters
You can use SSL counters to view SSL tunnel information and logs. Information about state machine transitions around connection establishment, additional states, and details are available to aid debugging.
The debug ssl state command provides the following information:
-
Remote device and interface with associated IPs, ports, and protocol.
-
Debugs for SSL connection establishment errors.
-
Debugs for verifying decrypted data padding length.
Use the show counters command to view the SSL counters. From Version 9.20.1, more SSL counters are available for debugging such as:
-
CNT_SSL_NP_CP_EVENT_NULL
-
CNT_SSL_NP_CP_EVENT_ENQUEUE_ERR
-
CNT_SSL_NP_CP_EVENT_RELEASE
-
CNT_SSL_NP_SNP_FLOW_HNDSHK_FAIL
-
CNT_SSL_NP_HDL_LOCK_RELEASE
-
CNT_SSL_NP_VERIFY_PADDING
-
CNT_SSL_NP_MAX_PAD_LEN_EXCEEDED
-
CNT_SSL_NP_NO_CIPHERS_COMPATIBLE
-
CNT_SSL_NP_CIPHER_LIC_NOT_GOOD
How to Remove Stuck ASP Table Entries
In Version 9.19.1 and earlier, if there are stuck ASP encrypt rules, you have to reboot the device. In Version 9.20.1 and later, you can remove the stuck encrypt rules from the ASP table using the debug menu asp 100 <encrypt_rule_id> command without rebooting the device. Use the show asp table classify domain encrypt command to find the encrypt_rule_id.
Guidelines
-
As debugging output is assigned high priority in the CPU process, it can render the system unusable. We recommend that you use this debug command only during troubleshooting sessions with Cisco TAC.
-
There is no validation to check if the rule is stuck. The device will crash if the system tries to remove a rule that was previously removed using this command.
-
The command ID parameter must exactly match an actual ID from the ASP table.
Example
In the following example, traffic gets dropped when traffic hits the stuck rule 0x7f039846aaaa instead of hitting the good rule 0x7f039846bbbb. You can identify the stuck rule from the hit counts. The hit count for the stuck rule is 9999 while that of the good rule is 0.
-
Use the show asp table classify domain encrypt command to view the ASP rules.
ASAv(config)# show asp table classify domain encrypt...out id=0x7f039846aaaa, priority=70, domain=encrypt, deny=falsehits=9999, user_data=0xaaaa, cs_id=0x7f03941866e0, reverse, flags=0x0, protocol=0src ip/id=1.0.0.0, mask=255.0.0.0, port=0, tag=anydst ip/id=2.0.0.0, mask=255.0.0.0, port=0, tag=anysrc nsg_id=none, dst nsg_id=nonedscp=0x0, input_ifc=any, output_ifc=outsideout id=0x7f039846bbbb, priority=70, domain=encrypt, deny=false //this is a good rulehits=0, user_data=0xbbbb, cs_id=0x7f03941866e0, reverse, flags=0x0, protocol=0src ip/id=1.0.0.0, mask=255.0.0.0, port=0, tag=anydst ip/id=2.0.0.0, mask=255.0.0.0, port=0, tag=anysrc nsg_id=none, dst nsg_id=nonedscp=0x0, input_ifc=any, output_ifc=outside... -
Use the debug menu asp 100 <encrypt_rule_id> command to remove the stuck encrypt rules from the ASP table
ASAv(config)# debug menu asp 100 id=0x7f039846aaaaEncrypt rule 0x7f0398469510 was successfully deleted. -
Use the show asp table classify domain encrypt command to verify if ASA has removed the stuck ASP rule.
ASAv(config)# show asp table classify domain encrypt...out id=0x7f039846bbbb, priority=70, domain=encrypt, deny=false //now this rule has hitshits=10, user_data=0xbbbb, cs_id=0x7f03941866e0, reverse, flags=0x0, protocol=0src ip/id=1.0.0.0, mask=255.0.0.0, port=0, tag=anydst ip/id=2.0.0.0, mask=255.0.0.0, port=0, tag=anysrc nsg_id=none, dst nsg_id=nonedscp=0x0, input_ifc=any, output_ifc=outside
![CLI Book 3: Cisco Secure Firewall ASA VPN CLI Configuration Guide, 9.22 - General VPN Parameters [Cisco Secure Firewall ASA] (2024)](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mP8/h8AAvMB+NzmkbcAAAAASUVORK5CYII=)