Usage Guidelines

You can enable disconnect notifications to peers with the use of the following delete reasons:

• IKE_DELETE_RESERVED = 0An invalid code. Do not send.

• IKE_DELETE_BY_ERROR = 1A transmission error for a timeout or failure when expecting a response to a keepalive or any other IKE packet ACK. The default text is “Connectivity to client lost.”

• IKE_DELETE_BY_USER_COMMAND = 2The SA was actively deleted with manual intervention by the user or administrator. The default text is “Manually Disconnected by Administrator.”

• IKE_DELETE_BY_EXPIRED_LIFETIME = 3The SA has expired. The default text is “Maximum Configured Lifetime Exceeded.”

• IKE_DELETE_NO_ERROR = 4An unknown error caused the delete.

• IKE_DELETE_SERVER_SHUTDOWN = 5The server is being shut down.

• IKE_DELETE_SERVER_IN_FLAMES = 6The server has some severe problems. The default text is “Peer is having heat problems.”

• IKE_DELETE_MAX_CONNECT_TIME = 7The maximum allowed time of an active tunnel has expired. Unlike EXPIRED_LIFETIME, this reason indicates that the entire IKE-negotiated/controlled tunnel is being disconnected, not just this one SA. The default text is “Maximum Configured Connection Time Exceeded.”

• IKE_DELETE_IDLE_TIMEOUT = 8The tunnel has been idle for the maximum allowed time; therefore, the entire IKE-negotiated tunnel has been disconnected, not just this one SA. The default text is “Maximum Idle Time for Session Exceeded.”

• IKE_DELETE_SERVER_REBOOT = 9The server is rebooting.

• IKE_DELETE_P2_PROPOSAL_MISMATCH = 10Phase2 proposal mismatch.

• IKE_DELETE_FIREWALL_MISMATCH = 11Firewall parameter mismatch.

• IKE_DELETE_CERT_EXPIRED = 12User certification required. The default message is “User or Root Certificate has Expired.”

• IKE_DELETE_CLIENT_NOT_ALLOWED = 13Client type or version not allowed.

• IKE_DELETE_FW_SERVER_FAIL = 14Failed to contact Zone Integrity Server.

• IKE_DELETE_ACL_ERROR = 15ACL downloaded from AAA cannot be inserted. The default message is “ACL parsing error.”

Usage Guidelines

NAT including PAT is used in many networks where IPsec is also used, but there are a number of incompatibilities that prevent IPsec packets from successfully traversing NAT devices. NAT traversal enables ESP packets to pass through one or more NAT devices.

The ASA supports NAT traversal as described by Version 2 and Version 3 of the IETF “UDP Encapsulation of IPsec Packets” draft, available at http://www.ietf.org/html.charters/ipsec-charter.html , and supports NAT traversal for both dynamic and static crypto maps.

This command enables NAT-T globally on the ASA. To disable in a crypto-map entry, use the crypto map set nat-t-disable command.

Usage Guidelines

IKE policies define a set of parameters for IKE negotiation.

If you specify RSA signatures, you must configure the ASA and its peer to obtain certificates from a CA server. If you specify preshared keys, you must configure these preshared keys separately within the ASA and its peer.

Usage Guidelines

IKE policies define a set of parameters to use during IKE negotiation.

There are three group options: 768-bit (DH Group 1), 1024-bit (DH Group 2), and 1536-bit (DH Group 5). The 1024-bit and 1536-bit Diffie-Hellman Groups provide stronger security, but require more CPU time to execute.

Note

The Cisco VPN Client Version 3.x or higher requires ISAKMP policy to use DH group 2. (If you configure DH group 1, the Cisco VPN Client cannot connect.)AES support is available on ASAs licensed for VPN-3DES only. Due to the large key sizes provided by AES, ISAKMP negotiation should use Diffie-Hellman (DH) group 5 instead of group 1 or group 2. To configures group 5, use the crypto isakmp policy priority group 5 command.

Usage Guidelines

IKE policies define a set of parameters to be used during IKE negotiation.

There are two hash algorithm options: SHA-1 and MD5. MD5 has a smaller digest and is considered to be slightly faster than SHA-1.

Usage Guidelines

When IKE begins negotiations, it seeks to agree upon the security parameters for its own session. Then the security association at each peer refers to the agreed-upon parameters. The peers retain the security association until the lifetime expires. You can specify an infinite lifetime if the peer does not propose a lifetime. Before a security association expires, subsequent IKE negotiations can use it, which can save time when setting up new IPsec security associations. The peers negotiate new security associations before current security associations expire.

With longer lifetimes, the ASA sets up future IPsec security associations more quickly. Encryption strength is great enough to ensure security without using very fast rekey times, on the order of every few minutes. We recommend that you accept the default.

Note	If the IKE security association is set to an infinite lifetime, but the peer proposes a finite lifetime, then the negotiated finite lifetime from the peer is used.

Usage Guidelines

Use the crypto key generate command to generate key pairs to support SSL, SSH, and IPsec connections. The generated key pairs are identified by labels that you can provide as part of the command syntax. Trustpoints that do not reference a key pair can use the default one, Default-type-Key. SSH connections always use this key. This does not affect SSL, because SSL generates its own certificate or key dynamically, unless a trustpoint has one configured.

For SSH, existing smaller keys can continue to be used after upgrading to 9.16, but we recommend that you upgrade to a larger size, or to a higher security key type. For other features, these RSA keys cannot be used in 9.16 and later. You can use the crypto ca permit-weak-crypto command to allow use of existing smaller keys, but even with this command, you cannot generate new smaller RSA keys.

Usage Guidelines

This command is only available on the ASA 5510, ASA 5520, ASA 5540, and 5550. The command is not available on the ASA 5580.

Usage Guidelines

Use this command to assign a crypto map set to any active ASA interface. The ASA supports IPsec termination on any and all active interfaces. You must assign a crypto map set to an interface before that interface can provide IPsec services.

You can assign only one crypto map set to an interface. If multiple crypto map entries have the same map name but a different sequence number, they are part of the same set and are all applied to the interface. The ASA evaluates the crypto map entry with the lowest sequence number first.

Use the ipv6-local-address keyword when you have multiple IPv6 addresses configured on an interface and are configuring the ASA to support LAN-to-LAN VPN tunnels in an IPv6 environment.

Note

The ASA lets you change crypto map, dynamic map, and IPsec settings on the fly. If you do so, the ASA brings down only the connections affected by the change. If you change an existing access list associated with a crypto map, specifically by deleting an entry within the accesslist, the result is that only the associated connection is brought down. Connections based on other entries in the access list are not affected.Every static crypto map must define three parts: an access list, a transform set, and an IPsec peer. If one of these is missing, the crypto map is incomplete and the ASA moves on to the next entry. However, if the crypto map matches the access list but not either or both of the other two requirements, this ASA drops the traffic. Use the show running-config crypto map command to ensure that every crypto map is complete. To fix an incomplete crypto map, remove the crypto map, add the missing entries, and reapply it.

Usage Guidelines

After you define crypto map entries, you can use the crypto map interface command to assign the dynamic crypto map set to interfaces.

Dynamic crypto maps provide two functions: filtering/classifying traffic to protect, and defining the policy to apply to that traffic. The first use affects the flow of traffic on an interface; the second affects the negotiation performed (via IKE) on behalf of that traffic.

IPsec dynamic crypto maps identify the following:

• The traffic to protect

• IPsec peer(s) with which to establish a security association

• Transform sets to use with the protected traffic

• How to use or manage keys and security associations

A crypto map set is a collection of crypto map entries, each with a different sequence number (seq-num ) but the same map name. Therefore, for a given interface, you could have certain traffic forwarded to one peer with specified security applied to that traffic, and other traffic forwarded to the same or a different peer with different IPsec security applied. To accomplish this, you create two crypto map entries, each with the same map name, but each with a different sequence number.

The number you assign as the seq-num argument should not be arbitrary. This number ranks multiple crypto map entries within a crypto map set. A crypto map entry with a lower sequence number is evaluated before a map entry with a higher sequence number; that is, the map entry with the lower number has a higher priority.

Note

When you link the crypto map to a dynamic crypto map, you must specify the dynamic crypto map. This links the crypto map to an existing dynamic crypto map that was previously defined using the crypto dynamic-map command. Now any changes you make to the crypto map entry after it has been converted will not take affect. For example, a change to the set peer setting does not take effect. However, the ASA stores the change while it is up. When the dynamic crypto map is converted back to the crypto map, the change is effective and appears in the output of the show running-config crypto map command. The ASA maintains these settings until it reboots.

Usage Guidelines

This command is required for all static crypto maps. If you are defining a dynamic crypto map (with the crypto dynamic-map command), this command is not required but is strongly recommended.

Use the access-list command to define the access lists. The access list hit counts only increase when the tunnel initiates. After the tunnel is up, the hit counts do not increase on a per-packet flow. If the tunnel drops and then reinitiates, the hit count will be increased.

The ASA uses the access lists to differentiate the traffic to protect with IPsec crypto from the traffic that does not need protection. It protects outbound packets that match a permit ACE, and ensures that inbound packets that match a permit ACE have protection.

When the ASA matches a packet to a deny statement, it skips the evaluation of the packet using the remaining ACEs in the crypto map, and resumes evaluation of the packet using the ACEs in the next crypto map in sequence. Cascading ACLs involves the use of deny ACEs to bypass evaluation of the remaining ACEs in an ACL, and the resumption of evaluation of traffic using the ACL assigned to the next crypto map in the crypto map set. Because you can associate each crypto map with different IPsec settings, you can use deny ACEs to exclude special traffic from further evaluation in the corresponding crypto map, and match the special traffic to permit statements in another crypto map to provide or require different security.

Note

The crypto access list does not determine whether to permit or deny traffic through the interface. An access list applied directly to the interface with the access-group command makes that determination. In transparent mode, the destination address should be the IP address of the ASA, the management address. Only tunnels to the ASA are allowed in transparent mode.

Usage Guidelines

The crypto map set connection-type command specifies the connection types for the backup LAN-to-LAN feature. It allows multiple backup peers to be specified at one end of the connection.

This feature works only between the following platforms:

• Two Cisco ASA 5500 series

• A Cisco ASA 5500 series and a Cisco VPN 3000 concentrator

• A Cisco ASA 5500 series and a security appliance running Cisco PIX security appliance software Version 7.0, or higher

To configure a backup LAN-to-LAN connection, we recommend that you configure one end of the connection as originate-only using the originate-only keyword, and the end with multiple backup peers as answer-only using the answer-only keyword. On the originate-only end, use the crypto map set peer command to order the priority of the peers. The originate-only ASA attempts to negotiate with the first peer in the list. If that peer does not respond, the ASA works its way down the list until either a peer responds or there are no more peers in the list.

Note	IKEv2 does not support backup site to site, which is set when using the originate-only or answer-only keyword. The cryto map set connection-type must be bidirectional when using IKEv2.

When configured in this way, the originate-only peer initially attempts to establish a proprietary tunnel and negotiate with a peer. Thereafter, either peer can establish a normal LAN-to-LAN connection and data from either end can initiate the tunnel connection.

In transparent firewall mode, you can see this command but the connection-type value cannot be set to anything other than answer-only for crypto map entries that are part of a crypto map that has been attached to the interface.

<xref> lists all supported configurations. Other combinations may result in unpredictable routing issues.

Usage Guidelines

The original DF policy command is retained and acts as a global policy setting on an interface, but it is superseded for an SA by the crypto map command.

Usage Guidelines

Phase 1 IKEv1 negotiations can use either main mode or aggressive mode. Both provide the same services, but aggressive mode requires only two exchanges between the peers totaling three messages, rather than three exchanges totaling six messages.

The aggressive mode is faster because it uses only three messages, to exchange data and identify the two VPN endpoints. The identification of the VPN endpoints makes Aggressive Mode less secure.

When you use Aggressive mode, the number of exchanges between two endpoints is fewer than it would be if you used Main Mode, and the exchange relies mainly on the ID types used in the exchange by both appliances. Aggressive Mode does not ensure the identity of the peer. Main Mode ensures the identity of both peers, but can only be used if both sides have a static IP address. If your device has a dynamic IP address, you should use Aggressive mode for Phase 1.

This command works only in initiator mode; not in responder mode. Including a Diffie-Hellman group with aggressive mode is optional. If one is not included, the ASA uses group 2.

Usage Guidelines

For all crypto map entries, an IKEv1 transform set or an IKEv2 proposal is required.

The peer at the opposite end of the IPsec IKEv2 initiation uses the first matching proposal for the security association. If the local ASA initiates the negotiation, the order specified in the crypto map command determines the order in which theASA presents the contents of the proposals to the peer. If the peer initiates the negotiation, the local ASA uses the first proposal in the crypto map entry that matches the IPsec parameters sent by the peer.

If the peer at the opposite end of the IPsec initiation fails to match the values of the proposals, IPsec does not establish a security association. The initiator drops the traffic because there is no security association to protect it.

To change the list of proposals, create a new list and specify it to replace the old one.

If you use this command to modify a crypto map, the ASA modifies only the crypto map entry with the same sequence number you specify. For example, the ASA inserts the proposal named 56des-sha in the last position if you enter the following commands:

ciscoasa(config)# crypto map map1 1 set ikev2 ipsec-proposal 
128aes-md5
 
128aes-sha
 
192aes-md5
 
ciscoasa(config)# crypto map map1 1 set ikev2 ipsec-proposal 
56des-sha
ciscoasa(config)# 

The response to the following command shows the cumulative effect of the previous two commands:

ciscoasa(config)# show running-config crypto map
crypto map map1 1 set ipsec-proposal 128aes-md5 128aes-sha 192aes-md5 56des-sha
ciscoasa(config)#

To reconfigure the sequence of proposals in a crypto map entry, delete the entry, specifying both the map name and sequence number; then recreate it. For example, the following commands reconfigure the crypto map entry named map2, sequence 3:

asa2(config)# no crypto map map2 3 set 
ikev2 
ipsec-proposal
asa2(config)# crypto map map2 3 set 
ikev2 
ipsec-proposal 192aes-sha 192aes-md5 128aes-sha 128aes-md5
asa2(config)# 

Usage Guidelines

For IKEv2, specify the mode for applying ESP encryption and authentication to the tunnel. This determines what part of the original IP packet has ESP applied.

Where tunnel encapsulation mode is the default. transport encapsulation mode is transport mode with the option to fallback to tunnel mode if the peer does not support it, and transport-require encapsulation mode enforces transport mode only. Transport mode is not recommended for Remote Access VPNs.

• Tunnel mode—(default) Encapsulation mode will be tunnel mode. Tunnel mode applies ESP encryption andauthentication to the entire original IP packet (IP header and data), thus hiding the ultimate source and destinationaddresses.The entire original IP datagram is encrypted, and it becomes the payload in a new IP packet.

This mode allows a network device, such as a router, to act as an IPsec proxy. That is, the router performs encryption on behalf of the hosts. The source router encrypts packets and forwards them along the IPsec tunnel. The destination router decrypts the original IP datagram and forwards it on to the destination system. The major advantage of tunnel mode is that the end systems do not need to be modified to receive the benefits of IPsec. Tunnel mode also protects against traffic analysis; with tunnel mode, an attacker can only determine the tunnel endpoints and not the true source and destination of the tunneled packets, even if they are the same as the tunnel endpoints.

• Transport mode— Encapsulation mode will be transport mode with option to fallback on tunnel mode, if peer does not support it. In Transport mode only the IP payload is encrypted, and the original IP headers are left intact.

This mode has the advantages of adding only a few bytes to each packet and allowing devices on the public network to see the final source and destination of the packet. With transport mode, you can enable special processing (for example, QoS) on the intermediate network based on the information in the IP header. However, the Layer 4 header is encrypted, which limits examination of the packet.

• Transport Required— Encapsulation mode will be transport mode only, falling back to tunnel mode is not allowed.

Negotiation of the encapsulation mode is as follows:

• If the initiator proposes transport mode, and the responder responds with tunnel mode, the initiator will fall back to Tunnel mode.

• If the initiator proposes tunnel mode, and responder responds with transport mode, the responder will fallback to Tunnel mode.

• If the initiator proposes tunnel mode and responder has transport-require mode, then NO PROPOSAL CHOSEN will be sent by the responder.

• Similarly if initiator has transport-require, and responder has tunnel mode, NO PROPOSAL CHOSEN will be sent by the responder.

Usage Guidelines

This command works only in initiator mode; not in responder mode. Including a Diffie-Hellman group with aggressive mode is optional. If one is not included, the ASA uses group 2.

Usage Guidelines

This command works only when the ASA is initiating the tunnel, not when responding to a tunnel. Using the data setting may create a large number of IPsec SAs. This consumes memory and results in fewer overall tunnels. You should use the data setting only for extremely security-sensitive applications.

Usage Guidelines

Use the isakmp nat-traversal command to globally enable NAT-T. Then you can use the crypto map set nat-t-disable command to disable NAT-T for specific crypto map entries.

Usage Guidelines

This command is required for all static crypto maps. If you are defining a dynamic crypto map (with the crypto dynamic-map command), this command is not required, and in most cases is not used because the peer is usually unknown.

Configuring multiple peers is equivalent to providing a fallback list. For each tunnel, the ASA attempts to negotiate with the first peer in the list. If that peer does not respond, the ASA works its way down the list until either a peer responds or there are no more peers in the list. You can set up multiple peers only when using the backup LAN-to-LAN feature (that is, when the crypto map connection type is originate-only). For more information, see the crypto map set connection-type command.

Note	From 9.14(1), multiple peers are supported for IKEv2.

Usage Guidelines

With PFS, each time a new security association is negotiated, a new Diffie-Hellman exchange occurs, which requires additional processing time. PFS adds another level of security because if one key is ever cracked by an attacker, only the data sent with that key is compromised.

During negotiation, this command causes IPsec to request PFS when requesting new security associations for the crypto map entry. If the set pfs statement does not specify a group, the ASA sends the default. The default is group2 for releases prior to 9.13, and group14 for release 9.13 and later.

If the peer initiates the negotiation and the local configuration specifies PFS, the peer must perform a PFS exchange or the negotiation fails. If the local configuration does not specify a group, the ASA assumes the default group. If the local configuration specifies a group, that group must be part of the peer’s offer or the negotiation fails.

For a negotiation to succeed, PFS has to be set on both ends of the LAN to LAN tunnel (with or without the Diffie-Hellman group). If set, the groups have to be an exact match. The ASA does not accept just any offer of PFS from the peer.

In general, higher groups provide more security than lower groups, but they require more processing time than the lower groups.

When interacting with the Cisco VPN Client, the ASA does not use the PFS value, but instead uses the value negotiated during Phase 1.

Usage Guidelines

Do not enable RRI if you specify any source/destination (0.0.0.0/0.0.0.0) as the protected network, because this will impact traffic that uses your default route.

If dynamic is not specified, RRI is done upon configuration and is considered static, remaining in place until the configuration changes or is removed. The ASA automatically adds static routes to the routing table and announces these routes to its private network or border routers using OSPF.

If dynamic is specified, routes are created upon the successful establishment of IPsec security associations (SA's). Routes will be added based on the negotiated selector information. The routes will be deleted after the IPsec SA's are deleted. Also, a configuration change from dynamic to static and vice-versa causes the existing IPsec tunnels for that crypto map to be torn down.

Typically, RRI routes are used to Initiate a tunnel if one is not present and traffic needs to be encrypted. With dynamic RRI support, no routes are present before the tunnel is brought up. Therefore, an ASA with dynamic RRI configured would typically work only as a responder.

Dynamic RRI applies to IKEv2 based static crypto maps only.

Usage Guidelines

The crypto map's security associations are negotiated according to the global lifetimes.

IPsec security associations use shared secret keys. These keys and their security associations time out together.

Assuming that the particular crypto map entry has lifetime values configured, when the ASA requests new security associations during security association negotiation, it specifies its crypto map lifetime values in the request to the peer; it uses these values as the lifetime of the new security associations. When the ASA receives a negotiation request from the peer, it uses the smaller of the lifetime values proposed by the peer or the locally configured lifetime values as the lifetime of the new security associations.

For site-to-site VPN connections, there are two lifetimes: a “timed” lifetime and a “traffic-volume” lifetime. The security association expires after the first of these lifetimes is reached. For remote access VPN sessions, only the timed lifetime applies.

Note

The ASA lets you change crypto map, dynamic map, and IPsec settings on-the-fly. If you do so, the ASA brings down only the connections affected by the change. If you change an existing access list associated with a crypto map, specifically by deleting an entry within the access list, the result is that only the associated connection is brought down. Connections based on other entries in the access list are not affected.

Note	We recommend that you configure different security association timers on either side of the site-to-site IKEv2 tunnel to avoid the rekey collision.

To change the timed lifetime, use the crypto map set security-association lifetime seconds command. The timed lifetime causes the keys and security association to time out after the specified number of seconds have passed.

Usage Guidelines

This command configures the existing DF policy (at an SA level) for the crypto map.

Usage Guidelines

This command is required for all crypto map entries.

The peer at the opposite end of the IPsec initiation uses the first matching transform set for the security association. If the local ASA initiates the negotiation, the order specified in the crypto map command determines the order in which the ASA presents the contents of the transform sets to the peer. If the peer initiates the negotiation, the local ASA uses the first transform set in the crypto map entry that matches the IPsec parameters sent by the peer.

If the peer at the opposite end of the IPsec initiation fails to match the values of the transform sets, IPsec does not establish a security association. The initiator drops the traffic because there is no security association to protect it.

To change the list of transform sets, specify a new list to replace the old one.

If you use this command to modify a crypto map, the ASA modifies only the crypto map entry with the same sequence number you specify. For example, the ASA inserts the transform set named 56des-sha in the last position if you enter the following commands:

ciscoasa(config)# crypto map map1 1 set transform-set 
128aes-md5
 
128aes-sha
 
192aes-md5
 
ciscoasa(config)# crypto map map1 1 transform-set 
56des-sha
ciscoasa(config)# 

The response to the following command shows the cumulative effect of the previous two commands:

ciscoasa(config)# show running-config crypto map
crypto map map1 1 set transform-set 128aes-md5 128aes-sha 192aes-md5 56des-sha
ciscoasa(config)# 

To reconfigure the sequence of transform sets in a crypto map entry, delete the entry, specifying both the map name and sequence number; then recreate it. For example, the following commands reconfigure the crypto map entry named map2, sequence 3:

asa2(config)# no crypto map map2 3 set transform-set
 
asa2(config)# crypto map map2 3 set transform-set 192aes-sha 192aes-md5 128aes-sha 128aes-md5
asa2(config)# 

Usage Guidelines

This crypto map command is valid only for initiating a connection. For information on the responder side, see the tunnel-group commands.

Usage Guidelines

This crypto map command is valid only for validating incoming ICMP error messages.

Usage Guidelines

Class configuration mode is accessible from policy map configuration mode.

The csc command configures a security policy to send to the CSC SSM all traffic that is matched by the applicable class map. This occurs before the ASA allows the traffic to continue to its destination.

You can specify how the ASA treats matching traffic when the CSC SSM is not available to scan the traffic. The fail-open keyword specifies that the ASA permits the traffic to continue to its destination even though the CSC SSM is not available. The fail-close keyword specifies that the ASA never lets matching traffic continue to its destination when the CSC SSM is not available.

The CSC SSM can scan HTTP, SMTP, POP3, and FTP traffic. It supports these protocols only when the destination port of the packet requesting the connection is the well-known port for the protocol, that is, CSC SSM can scan only the following connections:

• FTP connections opened to TCP port 21

• HTTP connections opened to TCP port 80

• POP3 connections opened to TCP port 110

• SMTP connections opened to TCP port 25

If policies using the csc command select connections that misuse these ports for other protocols, the ASA passes the packets to the CSC SSM; however, the CSC SSM passes the packets without scanning them.

To maximize the efficiency of the CSC SSM, configure class maps used by policies implementing the csc command as follows:

• Select only the supported protocols that you that want the CSC SSM to scan. For example, if you do not want to scan HTTP traffic, be sure that service policies do not divert HTTP traffic to the CSC SSM.

• Select only those connections that risk trusted hosts protected by the ASA. These are connections from outside or untrusted networks to inside networks. We recommend scanning the following connections:

  • Outbound HTTP connections

  • FTP connections from clients inside the ASA to servers outside the ASA

  • POP3 connections from clients inside the ASA to servers outside the ASA

  • Incoming SMTP connections destined to inside mail servers

FTP Scanning

The CSC SSM supports scanning of FTP file transfers only if the primary channel for the FTP session uses the standard port, which is TCP port 21.

FTP inspection must be enabled for the FTP traffic that you want scanned by the CSC SSM. This is because FTP uses a dynamically assigned secondary channel for data transfer. The ASA determines the port assigned for the secondary channel and opens a pinhole to allow the data transfer to occur. If the CSC SSM is configured to scan FTP data, the ASA diverts the data traffic to the CSC SSM.

You can apply FTP inspection either globally or to the same interface that the csc command is applied to. By default, FTP inspection is enabled globally. If you have not changed the default inspection configuration, no further FTP inspection configuration is required to enable FTP scanning by the CSC SSM.

For more information about FTP inspection or the default inspection configuration, see the CLI configuration guide.

Usage Guidelines

CSD is enabled or disabled globally for all remote access connection attempts made to the ASA with one exception.

The csd enable command does the following:

1. Provides a validity check that supplements the check performed by the previous csd image path command.

2. Creates an sdesktop folder on disk0: if one is not already present.

3. Inserts a data.xml (Cisco Secure Desktop configuration) file in the sdesktop folder if one is not already present.

4. Loads the data.xml from the flash device to the running configuration.

5. Enables CSD.

Note	You can enter the show webvpn csd command to determine whether or not Cisco Secure Desktop is enabled.

• The csd image path command must be in the running configuration before you enter the csd enable command.

• The no csd enable command disables CSD in the running configuration. If CSD is disabled, you cannot access CSD Manager and remote users cannot use CSD.

• If you transfer or replace the data.xml file, disable and then enable CSD to load the file into the running configuration.

• CSD is enabled or disabled globally for all remote access connection attempts made to the ASA. You cannot enable or disable CSD for an individual connection profile or group policy.

Exception : Connection profiles for clientless SSL VPN connections can be configured so that CSD will not run on the client computer if the computer is attempting to connect to the ASA using a group URL and CSD is enabled globally. For example:

ciscoasa(config)# tunnel-group group-name webvpn-attributes

ciscoasa(config-tunnel-webvpn)# group-url https://www.url-string.com

ciscoasa(config-tunnel-webvpn)# without-csd