Cisco ASA 1000V ASDM Configuration Guide, 6.7
Configuring IKE
Downloads: This chapterpdf (PDF - 216.0KB) The complete bookPDF (PDF - 11.09MB) | Feedback

Configuring IKE

Table Of Contents

Configuring IKE

Setting IKE Parameters

Creating IKE Policies

Add/Edit IKEv1 Policy

Add/Edit IKEv2 Policy (Proposal)

Configuring IPsec

Adding Crypto Maps

Creating an IPsec Rule/Tunnel Policy (Crypto Map) - Basic Tab

Creating IPsec Rule/Tunnel Policy (Crypto Map) - Advanced Tab

Creating IPsec Rule/Traffic Selection Tab

Pre-Fragmentation

Edit IPsec Pre-Fragmentation Policy

IPsec Transform Sets

Add/Edit IPsec Proposal (Transform Set)

Add/Edit IPsec Proposal


Configuring IKE


IKE, also called ISAKMP, is the negotiation protocol that lets two hosts agree on how to build an IPsec security association. To configure the ASA 1000V for virtual private networks, you set global IKE parameters that apply system wide, and you also create IKE policies that the peers negotiate to establish a VPN connection.

This chapter describes how to configure IKE, load balancing, and NAC. It includes the following sections:

Setting IKE Parameters

Creating IKE Policies

Configuring IPsec

Setting IKE Parameters

This pane lets you set system wide values for VPN connections. The following sections describe each of the options.

Enabling IKE on Interfaces

You must enable IKE for each interface that you want to use for VPN connections.

Enabling IPsec over NAT-T

NAT-T lets IPsec peers establish both remote access and LAN-to-LAN connections through a NAT device. It does this by encapsulating IPsec traffic in UDP datagrams, using port 4500, thereby providing NAT devices with port information. NAT-T auto-detects any NAT devices, and only encapsulates IPsec traffic when necessary. This feature is disabled by default.

The ASA 1000V implementation of NAT-T supports IPsec peers behind a single NAT/PAT device as follows:

One LAN-to-LAN connection.

To use NAT-T you must:

Open port 4500 on the ASA 1000V.

Enable IPsec over NAT-T globally in this pane.

Choose the second or third option for the Fragmentation Policy parameter in the Configuration > VPN > IPsec > Pre-Fragmentation pane. These options let traffic travel across NAT devices that do not support IP fragmentation; they do not impede the operation of NAT devices that do support IP fragmentation.

Determining ID Method

During IKE negotiations the peers must identify themselves to each other. You can choose the identification methods from the following options:

Address

Uses the IP addresses of the hosts exchanging ISAKMP identity information.

Hostname

Uses the fully-qualified domain name of the hosts exchanging ISAKMP identity information (default). This name comprises the hostname and the domain name.

Key ID

Uses the string the remote peer uses to look up the preshared key.

Automatic

Determines IKE negotiation by connection type:

IP address for preshared key


Disabling Inbound Aggressive Mode Connections

Phase 1 IKE negotiations can use either Main mode or Aggressive mode. Both provide the same services, but Aggressive mode requires only two exchanges between the peers, rather than three. Aggressive mode is faster, but does not provide identity protection for the communicating parties. It is therefore necessary that they exchange identification information prior to establishing a secure SA in which to encrypt in formation. This feature is disabled by default.

Alerting Peers Before Disconnecting

LAN-to-LAN sessions may be dropped for several reasons such as a ASA 1000V shutdown or reboot, session idle timeout, maximum connection time exceeded, or administrator cut-off.

The ASA 1000V can notify qualified peers in LAN-to-LAN sessions that are about to be disconnected, and it conveys to them the reason. The peer receiving the alert decodes the reason and displays it in the event log or in a pop-up pane. This feature is disabled by default.

This pane lets you enable the feature so that the ASA 1000V sends these alerts, and conveys the reason for the disconnect.

Waiting for Active Sessions to Terminate Prior to Reboot

You can schedule a ASA 1000V reboot to occur only when all active sessions have terminated voluntarily. This feature is disabled by default.

Preventing DoS Attacks by Limiting IKEv2 Open SAs

You can prevent denial-of-service (DoS) attacks for IPsec IKEv2 connections by always cookie challenging incoming SAs or by limiting the number of open SAs and cookie challenge any additional connections, or by By default, the ASA 1000V does not limit the number of open SAs and never cookie challenges SAs. You can also limit the number of SAs allowed, which stops further connections from negotiating to protect against memory and/or CPU attacks that the cookie-challenge feature may be unable to thwart and protects the current connections.

With a DoS attack, an attacker initiates the attack when the peer device sends an SA initiate packet and the ASA 1000V sends its response, but the peer device does not respond further. If the peer device does this continually, all the allowed SA requests on the ASA 1000V can be used up until it stops responding.

Enabling a threshold percentage for cookie challenging limits the number of open SA negotiations. For example, with the default setting of 50%, when 50% of the allowed SAs are in-negotiation (open), the ASA 1000V cookie challenges any additional SA initiate packets that arrive. For the Cisco ASA 5580 with 10000 allowed IKEv2 SAs, after 5000 SAs become open, any more incoming SAs are cookie-challenged.

If used in conjunction with the Number of SAs in Negotiation, or the Maximum Number of SAs Allowed, configure the cookie-challenge threshold lower than these settings for an effective cross-check.

Fields

Enable IKE—Shows IKE status for all configured interfaces.

Interface—Displays names of all configured ASA 1000V interfaces.

IKE Enabled—Shows whether IKE is enabled for each configured interface.

Enable/Disables—Click to enable or disable IKE for the highlighted interface.

NAT Transparency—Lets you enable or disable IPsec over NAT-T and IPsec over TCP.

Enable IPsec over NAT-T—Choose to enable IPsec over NAT-T.

NAT Keepalive—Type the number of seconds that can elapse with no traffic before the ASA 1000V terminates the NAT-T session. The default is 20 seconds. The range is 10 to 3600 seconds (one hour).

Enable IPsec over TCP—Choose to enable IPsec over TCP.

Enter up to 10 comma-separated TCP port values—Type up to 10 ports on which to enable IPsec over TCP. Use a comma to separate the ports. You do not need to use spaces. The default port is 10,000. The range is 1 to 65,635.

Identity to Be Sent to Peer—Lets you set the way that IPsec peers identify themselves to each other.

Identity—Choose one of the following methods by which IPsec peers identify themselves:

Address

Uses the IP addresses of the hosts.

Hostname

Uses the fully-qualified domain names of the hosts. This name comprises the hostname and the domain name.

Key ID

Uses the string the remote peer uses to look up the preshared key.

Automatic

Determines IKE negotiation by connection type: IP address for preshared key.


Key Id String—Type the alpha-numeric string the peers use to look up the preshared key.

Disable inbound aggressive mode connections—Choose to disable aggressive mode connections.

Alert peers before disconnecting—Choose to have the ASA 1000V notify qualified LAN-to-LAN peers before disconnecting sessions.

Wait for all active sessions to voluntarily terminate before rebooting—Choose to have the ASA 1000V postpone a scheduled reboot until all active sessions terminate.

IKEv2 Specific Settings—These settings apply only to IPsec IKEv2 connections and limit the number of open SAs. By default, the ASA 1000V does not limit the number of open SAs:

Cookie Challenge—Enables the ASA 1000V to send cookie challenges to peer devices in response to SA initiate packets.

% threshold before incoming SAs are cookie challenged—The percentage of the total allowed SAs for the ASA 1000V that are in-negotiation, which triggers cookie challenges for any future SA negotiations. The range is zero to 100%. The default is 50%.

Number of Allowed SAs in Negotiation—Limits the maximum number of SAs that can be in negotiation at any time. If used in conjunction with Cookie Challenge, configure the cookie challenge threshold lower than this limit for an effective cross-check.

Maximum Number of SAs Allowed—Limits the number of allowed IKEv2 connections on the ASA 1000V. By default, the limit is the maximum number of connections specified by the license.

Modes

The following table shows the modes in which this feature is available:

Firewall Mode
Security Context
Routed
Transparent
Single
Multiple
Context
System


Creating IKE Policies

Each IKE negotiation is divided into two sections called Phase1 and Phase 2.

Phase 1 creates the first tunnel, which protects later IKE negotiation messages. Phase 2 creates the tunnel that protects data.

To set the terms of the IKE negotiations, you create one or more IKE policies, which include the following:

A unique priority (1 through 65,543, with 1 the highest priority).

An authentication method, to ensure the identity of the peers.

An encryption method, to protect the data and ensure privacy.

An HMAC method to ensure the identity of the sender, and to ensure that the message has not been modified in transit.

A Diffie-Hellman group to establish the strength of the of the encryption-key-determination algorithm. The ASA 1000V uses this algorithm to derive the encryption and hash keys.

A limit for how long the ASA 1000V uses an encryption key before replacing it.

For IKEv1, you can only enable one setting for each parameter. For IKEv2, each proposal can have multiples settings for Encryption, D-H Group, Integrity Hash, and PRF Hash.

If you do not configure any IKE policies, the ASA 1000V uses the default policy, which is always set to the lowest priority, and which contains the default value for each parameter. If you do not specify a value for a specific parameter, the default value takes effect.

When IKE negotiation begins, the peer that initiates the negotiation sends all of its policies to the remote peer, and the remote peer searches for a match with its own policies, in priority order.

A match between IKE policies exists if they have the same encryption, hash, authentication, and Diffie-Hellman values, and an SA lifetime less than or equal to the lifetime in the policy sent. If the lifetimes are not identical, the shorter lifetime—from the remote peer policy—applies. If no match exists, IKE refuses negotiation and the IKE SA is not established.

Fields

IKEv1 Policies—Displays parameter settings for each configured IKE policy.

Priority #—Shows the priority of the policy.

Encryption—Shows the encryption method.

Hash—Shows the hash algorithm.

D-H Group—Shows the Diffie-Hellman group.

Authentication—Shows the authentication method.

Lifetime (secs)—Shows the SA lifetime in seconds.

Add/Edit/Delete—Click to add, edit, or delete an IKEv1 policy.

IKEv2 Policies—Displays parameter settings for each configured IKEv2 policy.

Priority #—Shows the priority of the policy.

Encryption—Shows the encryption method.

Integrity Hash—Shows the hash algorithm.

PRF Hash—Shows the pseudo random function (PRF) hash algorithm.

D-H Group—Shows the Diffie-Hellman group.

Lifetime (secs)—Shows the SA lifetime in seconds.

Add/Edit/Delete—Click to add, edit, or delete an IKEv2 policy.

Modes

The following table shows the modes in which this feature is available:

Firewall Mode
Security Context
Routed
Transparent
Single
Multiple
Context
System


Add/Edit IKEv1 Policy

Fields

Priority #—Type a number to set a priority for the IKE policy. The range is 1 to 65535, with 1 the highest priority.

Encryption—Choose an encryption method. This is a symmetric encryption method that protects data transmitted between two IPsec peers.The choices follow:

des

56-bit DES-CBC. Less secure but faster than the alternatives. The default.

3des

168-bit Triple DES.

aes

128-bit AES.

aes-192

192-bit AES.

aes-256

256-bit AES.


Hash—Choose the hash algorithm that ensures data integrity. It ensures that a packet comes from whom you think it comes from, and that it has not been modified in transit.

sha

SHA-1

The default is SHA-1. MD5 has a smaller digest and is considered to be slightly faster than SHA-1. A successful (but extremely difficult) attack against MD5 has occurred; however, the HMAC variant IKE uses prevents this attack.

md5

MD5


Authentication—Choose pre-share (preshared keys) as the authentication method the ASA 1000V uses to establish the identity of each IPsec peer. Preshared keys do not scale well with a growing network but are easier to set up in a small network.

D-H Group—Choose the Diffie-Hellman group identifier, which the two IPsec peers use to derive a shared secret without transmitting it to each other.

1

Group 1 (768-bit)

The default, Group 2 (1024-bit Diffie-Hellman) requires less CPU time to execute but is less secure than Group 2 or 5.

2

Group 2 (1024-bit)

 

5

Group 5 (1536-bit)

 

Lifetime (secs)—Either check Unlimited or enter an integer for the SA lifetime. The default is 86,400 seconds or 24 hours. With longer lifetimes, the ASA 1000V 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.

Time Measure—Choose a time measure. The ASA 1000V accepts the following values:.

120 - 86,400 seconds

2 - 1440 minutes

1 - 24 hours

1 day


Modes

The following table shows the modes in which this feature is available:

Firewall Mode
Security Context
Routed
Transparent
Single
Multiple
Context
System


Add/Edit IKEv2 Policy (Proposal)

Fields

Priority #—Type a number to set a priority for the IKEv2 policy. The range is 1 to 65535, with 1 the highest priority.

Encryption—Choose an encryption method. This is a symmetric encryption method that protects data transmitted between two IPsec peers.The choices follow:

des

Specifies 56-bit DES-CBC encryption for ESP.

3des

(Default) Specifies the triple DES encryption algorithm for ESP.

aes

Specifies AES with a 128-bit key encryption for ESP.

aes-192

Specifies AES with a 192-bit key encryption for ESP.

aes-256

Specifies AES with a 256-bit key encryption for ESP.


D-H Group—Choose the Diffie-Hellman group identifier, which the two IPsec peers use to derive a shared secret without transmitting it to each other.

1

Group 1 (768-bit)

The default, Group 2 (1024-bit Diffie-Hellman) requires less CPU time to execute but is less secure than other groups.

2

Group 2 (1024-bit)

 

5

Group 5 (1536-bit)

 

14

Group 14 (2048-bit)

 

Integrity Hash—Choose the hash algorithm that ensures data integrity for the ESP protocol. It ensures that a packet comes from whom you think it comes from, and that it has not been modified in transit.

sha

SHA 1

The default is SHA 1. MD5 has a smaller digest and is considered to be slightly faster than SHA 1. A successful (but extremely difficult) attack against MD5 has occurred; however, the HMAC variant IKE uses prevents this attack.

md5

MD5

sha256

SHA 2, 256-bit digest

Specifies the Secure Hash Algorithm SHA 2 with the 256-bit digest.

sha384

SHA 2, 384-bit digest

Specifies the Secure Hash Algorithm SHA 2 with the 384-bit digest.

sha512

SHA 2, 512-bit digest

Specifies the Secure Hash Algorithm SHA 2 with the 512-bit digest.


Pseudo-Random Function (PRF)—Specify the PRF used for the construction of keying material for all of the cryptographic algorithms used in the SA.

sha

SHA-1

The default is SHA-1. MD5 has a smaller digest and is considered to be slightly faster than SHA-1. A successful (but extremely difficult) attack against MD5 has occurred; however, the HMAC variant IKE uses prevents this attack.

md5

MD5

sha256

SHA 2, 256-bit digest

Specifies the Secure Hash Algorithm SHA 2 with the 256-bit digest.

sha384

SHA 2, 384-bit digest

Specifies the Secure Hash Algorithm SHA 2 with the 384-bit digest.

sha512

SHA 2, 512-bit digest

Specifies the Secure Hash Algorithm SHA 2 with the 512-bit digest.


Lifetime (secs)—Either check Unlimited or enter an integer for the SA lifetime. The default is 86,400 seconds or 24 hours. With longer lifetimes, the ASA 1000V 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.

Time Measure—Choose a time measure. The ASA 1000V accepts the following values:.

120 - 86,400 seconds

2 - 1440 minutes

1 - 24 hours

1 day


Configuring IPsec

The ASA 1000V uses IPsec for LAN-to-LAN VPN connections, and provides the option of using IPsec for client-to-LAN VPN connections. In IPsec terminology, a "peer" is a remote-access client or another secure gateway.


Note The ASA supports LAN-to-LAN IPsec connections with Cisco peers (IPv4), and with third-party peers that comply with all relevant standards.


During tunnel establishment, the two peers negotiate security associations that govern authentication, encryption, encapsulation, and key management. These negotiations involve two phases: first, to establish the tunnel (the IKE SA); and second, to govern traffic within the tunnel (the IPsec SA).

A LAN-to-LAN VPN connects networks in different geographic locations. In IPsec LAN-to-LAN connections, the ASA 1000V can function as initiator or responder. In IPsec client-to-LAN connections, the ASA 1000V functions only as responder. Initiators propose SAs; responders accept, reject, or make counter-proposals—all in accordance with configured SA parameters. To establish a connection, both entities must agree on the SAs.

The ASA 1000V supports these IPsec attributes:

Main mode for negotiating phase one ISAKMP security associations when using digital certificates for authentication

Aggressive mode for negotiating phase one ISAKMP Security Associations (SAs) when using preshared keys for authentication

Authentication Algorithms:

ESP-MD5-HMAC-128

ESP-SHA1-HMAC-160

Authentication Modes:

Preshared Keys

Diffie-Hellman Groups 1, 2, and 5.

Encryption Algorithms:

AES-128, -192, and -256

3DES-168

DES-56

ESP-NULL

Extended Authentication (XAuth)

Mode Configuration (also known as ISAKMP Configuration Method)

Tunnel Encapsulation Mode

IP compression (IPCOMP) using LZS

Adding Crypto Maps

This pane shows the currently configured crypto maps, including the IPsec rules. Use it to add, edit, delete and move up, move down, cut, copy, and paste an IPsec rule.

Fields


Note You cannot edit, delete, or copy an implicit rule. The ASA 1000V implicitly accepts the traffic selection proposal from remote clients when configured with a dynamic tunnel policy. You can override it by giving a specific traffic selection.


Add—Click to launch the Create IPsec Rule dialog box, where you can configure basic, advanced, and traffic selection parameters for a rule.

Edit—Click to edit an existing rule.

Delete—Click to delete a rule highlighted in the table.

Cut—Deletes a highlighted rule in the table and keeps it in the clipboard for copying.

Copy—Copies a highlighted rule in the table.

Find—Click to enable the Find toolbar where you can specify the parameters of existing rules that you want to find:

Filter—Filter the find results by selecting Interface, Source, Destination, Destination Service, or Rule Query, selecting is or contains, and entering the filter parameter. Click ... to launch a browse dialog box that displays all existing entries that you can choose.

Diagram—Displays a diagram that illustrates the highlighted IPsec rule.

Type: Priority—Displays the type of rule (static or dynamic) and its priority.

Traffic Selection

#—Indicates the rule number.

Source—Indicates the IP addresses that are subject to this rule when traffic is sent to the IP addresses listed in the Remote Side Host/Network column. In detail mode (see the Show Detail button), an address column might contain an interface name with the word any, such as inside:any. any means that any host on the inside interface is affected by the rule.

Destination—Lists the IP addresses that are subject to this rule when traffic is sent from the IP addresses listed in the Security Appliance Side Host/Network column. In detail mode (see the Show Detail button), an address column might contain an interface name with the word any, such as outside:any. any means that any host on the outside interface is affected by the rule. Also in detail mode, an address column might contain IP addresses in square brackets, for example, [209.165.201.1-209.165.201.30]. These addresses are translated addresses. When an inside host makes a connection to an outside host, the ASA 1000V maps the inside host's address to an address from the pool. After a host creates an outbound connection, the ASA 1000V maintains this address mapping. This address mapping structure is called an xlate, and remains in memory for a period of time.

Service—Specifies the service and protocol specified by the rule (TCP, UDP, ICMP, or IP).

Action—Specifies the type of IPsec rule (protect or do not protect).

Transform Set—Displays the transform set for the rule.

Peer—Identifies the IPsec peer.

PFS—Displays perfect forward secrecy settings for the rule.

NAT-T Enabled—Indicates whether NAT Traversal is enabled for the policy.

Reverse Route Enabled—Indicates whether Reverse Route Injection is enabled for the policy.

Connection Type—(Meaningful only for static tunnel policies.) Identifies the connection type for this policy as bidirectional, originate-only, or answer-only).

SA Lifetime—Displays the SA lifetime for the rule.

IKE Negotiation Mode—Displays whether IKE negotiations use main or aggressive mode.

Description—(Optional) Specifies a brief description for this rule. For an existing rule, this is the description you typed when you added the rule. An implicit rule includes the following description: "Implicit rule." To edit the description of any but an implicit rule, right-click this column, and choose Edit Description or double-click the column.

Enable Anti-replay window size—Sets the anti-replay window size, between 64 and 1028 in multiples of 64. One side-effect of priority queueing in a hierarchical QoS policy with traffic shaping (see the "Rule Actions > QoS Tab") is packet re-ordering. For IPsec packets, out-of-order packets that are not within the anti-replay window generate warning syslog messages. These warnings becomes false alarms in the case of priority queueing. Configuring the anti-replay pane size helps you avoid possible false alarms.

Modes

The following table shows the modes in which this feature is available:

Firewall Mode
Security Context
Routed
Transparent
Single
Multiple
Context
System


Creating an IPsec Rule/Tunnel Policy (Crypto Map) - Basic Tab

Use this pane to define a new Tunnel Policy for an IPsec rule. The values you define here appear in the IPsec Rules table after you click OK. All rules are enabled by default as soon as they appear in the IPsec Rules table.

The Tunnel Policy pane lets you define a tunnel policy that is used to negotiate an IPsec (Phase 2) security association (SA). ASDM captures your configuration edits, but does not save them to the running configuration until you click Apply.

Every tunnel policy must specify a transform set and identify the security appliance interface to which it applies. The transform set identifies the encryption and hash algorithms that perform IPsec encryption and decryption operations. Because not every IPsec peer supports the same algorithms, you might want to specify a number of policies and assign a priority to each. The security appliance then negotiates with the remote IPsec peer to agree on a transform set that both peers support.

Tunnel policies can be static or dynamic. A static tunnel policy identifies one or more remote IPsec peers or subnetworks to which your security appliance permits IPsec connections. A static policy can be used whether your security appliance initiates the connection or receives a connection request from a remote host. A static policy requires you to enter the information necessary to identify permitted hosts or networks.

A dynamic tunnel policy is used when you cannot or do not want to provide information about remote hosts that are permitted to initiate a connection with the security appliance. If you are only using your security appliance as a VPN client in relation to a remote VPN central-site device, you do not need to configure any dynamic tunnel policies. Dynamic tunnel policies are most useful for allowing remote access clients to initiate a connection to your network through a security appliance acting as the VPN central-site device. A dynamic tunnel policy is useful when the remote access clients have dynamically assigned IP addresses or when you do not want to configure separate policies for a large number of remote access clients.

Fields

Interface—Choose the interface name to which this policy applies.

Policy Type—Choose the type, static or dynamic, of this tunnel policy.

Priority—Enter the priority of the policy.

IKE Proposals (Transform Sets)--Specifies IKEv1 and IKEv2 IPsec proposals:

IKEv1 IPsec Proposal—Choose the proposal (transform set) for the policy and click Add to move it to the list of active transform sets. Click Move Up or Move Down to rearrange the order of the proposals in the list box. You can add a maximum of 11 proposals to a crypto map entry or a dynamic crypto map entry.

IKEv2 IPsec Proposal—Choose the proposal (transform set) for the policy and click Add to move it to the list of active transform sets. Click Move Up or Move Down to rearrange the order of the proposals in the list box. You can add a maximum of 11 proposals to a crypto map entry or a dynamic crypto map entry.

Peer Settings - Optional for Dynamic Crypto Map Entries—Configure the peer settings for the policy.

Connection Type—(Meaningful only for static tunnel policies.) Choose bidirectional, originate-only, or answer-only to specify the connection type of this policy. For LAN-to-LAN connections, choose bidirectional or answer-only (not originate-only). Choose answer-only for LAN-to-LAN redundancy.

IP Address of Peer to Be Added—Enter the IP address of the IPsec peer you are adding.

Enable Perfect Forwarding Secrecy—Check to enable perfect forward secrecy for the policy. PFS is a cryptographic concept where each new key is unrelated to any previous key. In IPsec negotiations, Phase 2 keys are based on Phase 1 keys unless you specify Perfect Forward Secrecy.

Diffie-Hellman Group—When you enable PFS you must also choose a Diffie-Hellman group which the ASA 1000V uses to generate session keys. The choices are as follows:

Group 1 (768-bits) = Use perfect forward secrecy, and use Diffie-Hellman Group 1 to generate IPsec session keys, where the prime and generator numbers are 768 bits. This option is more secure but requires more processing overhead.

Group 2 (1024-bits) = Use perfect forward secrecy, and use Diffie-Hellman Group 2 to generate IPsec session keys, where the prime and generator numbers are 1024 bits. This option is more secure than Group 1 but requires more processing overhead.

Group 5 (1536-bits) = Use perfect forward secrecy, and use Diffie-Hellman Group 5 to generate IPsec session keys, where the prime and generator numbers are 1536 bits. This option is more secure than Group 2 but requires more processing overhead.

Modes

The following table shows the modes in which this feature is available:

Firewall Mode
Security Context
Routed
Transparent
Single
Multiple
Context
System


Creating IPsec Rule/Tunnel Policy (Crypto Map) - Advanced Tab

Fields

Security Association Lifetime parameters—Configures the duration of a Security Association (SA). This parameter specifies how to measure the lifetime of the IPsec SA keys, which is how long the IPsec SA lasts until it expires and must be renegotiated with new keys.

Time—Specifies the SA lifetime in terms of hours (hh), minutes (mm) and seconds (ss).

Traffic Volume—Defines the SA lifetime in terms of kilobytes of traffic. Enter the number of kilobytes of payload data after which the IPsec SA expires. Minimum is 100 KB, default is 10000 KB, maximum is 2147483647 KB.

Enable NAT-T— Enables NAT Traversal (NAT-T) for this policy.

Enable Reverse Route Injection—Enables Reverse Route Injection for this policy.
Reverse Route Injection (RRI) is used to populate the routing table of an internal router that runs dynamic routing protocols such as Open Shortest Path First (OSPF), or Enhanced Interior Gateway Routing Protocol (EIGRP), if you run ASA 8.0, or Routing Information Protocol (RIP) for LAN²LAN sessions.

Static Type Only Settings—Specifies parameters for static tunnel policies.

IKE Negotiation Mode—Chooses the IKE negotiation mode, Main or Aggressive. This parameter sets the mode for exchanging key information and setting up the SAs. It sets the mode that the initiator of the negotiation uses; the responder auto-negotiates. Aggressive Mode is faster, using fewer packets and fewer exchanges, but it does not protect the identity of the communicating parties. Main Mode is slower, using more packets and more exchanges, but it protects the identities of the communicating parties. This mode is more secure and it is the default selection. If you choose Aggressive, the Diffie-Hellman Group list becomes active.

Diffie-Hellman Group—Choose the Diffie-Hellman group to apply. The choices are as follows: Group 1 (768-bits), Group 2 (1024-bits), or Group 5 (1536-bits).

Modes

The following table shows the modes in which this feature is available:

Firewall Mode
Security Context
Routed
Transparent
Single
Multiple
Context
System


Creating IPsec Rule/Traffic Selection Tab

This pane lets you define what traffic to protect (permit) or not protect (deny).

Fields

Action—Specify the action for this rule to take. The selections are protect and do not protect.

Source—Specify the IP address, network object group or interface IP address for the source host or network. A rule cannot use the same address as both the source and destination. Click ... to launch the Browse Source dialog box that contains the following fields:

Add/Edit—Choose IP Address or Network Object Group to add more source addresses or groups.

Delete—Click to delete an entry.

Filter—Enter an IP Address to filter the results displayed.

Name—Indicates that the parameters that follow specify the name of the source host or network.

IP Address—Indicates that the parameters that follow specify the interface, IP address, and subnet mask of the source host or network.

Netmask—Chooses a standard subnet mask to apply to the IP address. This parameter appears when you choose the IP Address option button.

Description—Enter a description.

Selected Source—Click Source to include the selected entry as a source.

Destination—Specify the IP address, network object group or interface IP address for the destination host or network. A rule cannot use the same address as both the source and destination. Click ... to launch the Browse Destination dialog box that contains the following fields:

Add/Edit—Choose IP Address or Network Object Group to add more destination addresses or groups.

Delete—Click to delete an entry.

Filter—Enter an IP Address to filter the results displayed.

Name—Indicates that the parameters that follow specify the name of the destination host or network.

IP Address—Indicates that the parameters that follow specify the interface, IP address, and subnet mask of the destination host or network.

Netmask—Chooses a standard subnet mask to apply to the IP address. This parameter appears when you choose the IP Address option button.

Description—Enter a description.

Selected Destination—Click Destination to include the selected entry as a destination.

Service—Enter a service or click ... to launch the browse service dialog box where you can choose from a list of services.

Description—Enter a description for the Traffic Selection entry.

More Options

Enable Rule—Click to enable this rule.

Source Service—Enter a service or click ... to launch the browse service dialog box where you can choose from a list of services.

Time Range—Define a time range for which this rule applies.

Group—Indicates that the parameters that follow specify the interface and group name of the source host or network.

Interface—Choose the interface name for the IP address. This parameter appears when you choose the IP Address option button.

IP address—Specifies the IP address of the interface to which this policy applies. This parameter appears when you choose the IP Address option button.

Destination—Specify the IP address, network object group or interface IP address for the source or destination host or network. A rule cannot use the same address as both the source and destination. Click ... for either of these fields to launch the Browse dialog box that contain the following fields:

Name—Choose the interface name to use as the source or destination host or network. This parameter appears when you choose the Name option button. This is the only parameter associated with this option.

Interface—Choose the interface name for the IP address. This parameter appears when you choose the Group option button.

Group—Choose the name of the group on the specified interface for the source or destination host or network. If the list contains no entries, you can enter the name of an existing group. This parameter appears when you choose the Group option button.

Protocol and Service—Specifies protocol and service parameters relevant to this rule.


Note "Any - any" IPsec rules are not allowed. This type of rule would prevent the device and its peer from supporting multiple LAN -to-LAN tunnels.


TCP—Specifies that this rule applies to TCP connections. This selection also displays the Source Port and Destination Port group boxes.

UDP—Specifies that this rule applies to UDP connections. This selection also displays the Source Port and Destination Port group boxes.

ICMP—Specifies that this rule applies to ICMP connections. This selection also displays the ICMP Type group box.

IP—Specifies that this rule applies to IP connections. This selection also displays the IP Protocol group box.

Manage Service Groups—Displays the Manage Service Groups pane, on which you can add, edit, or delete a group of TCP/UDP services/ports.

Source Port and Destination Port —Contains TCP or UDP port parameters, depending on which option button you chose in the Protocol and Service group box.

Service—Indicates that you are specifying parameters for an individual service. Specifies the name of the service and a boolean operator to use when applying the filter.

Boolean operator (unlabeled)—Lists the boolean conditions (equal, not equal, greater than, less than, or range) to use in matching the service specified in the service box.

Service (unlabeled)—Identifies the service (such as https, kerberos, or any) to be matched. If you specified the range service operator this parameter becomes two boxes, into which you enter the start and the end of the range.

... —Displays a list of services from which you can choose the service to display in the Service box.

Service Group—Indicates that you are specifying the name of a service group for the source port.

Service (unlabeled)—Choose the service group to use.

ICMP Type—Specifies the ICMP type to use. The default is any. Click the ... button to display a list of available types.

Options

Time Range—Specify the name of an existing time range or create a new range.

... —Displays the Add Time Range pane, on which you can define a new time range.

Please enter the description below (optional)—Provides space for you to enter a brief description of the rule.

Modes

The following table shows the modes in which this feature is available:

Firewall Mode
Security Context
Routed
Transparent
Single
Multiple
Context
System


Pre-Fragmentation

Use this pane to set the IPsec pre-fragmentation policy and do-not-fragment (DF) bit policy for any interface.

The IPsec pre-fragmentation policy specifies how to treat packets that exceed the maximum transmission unit (MTU) setting when tunneling traffic through the public interface. This feature provides a way to handle cases where a router or NAT device between the ASA 1000V and the client rejects or drops IP fragments. For example, suppose a client wants to FTP get from an FTP server behind a ASA 1000V. The FTP server transmits packets that when encapsulated would exceed the ASA 1000V's MTU size on the public interface. The selected options determine how the ASA 1000V processes these packets. The pre-fragmentation policy applies to all traffic travelling out the ASA 1000V public interface.

The ASA 1000V encapsulates all tunneled packets. After encapsulation, the ASA 1000V fragments packets that exceed the MTU setting before transmitting them through the public interface. This is the default policy. This option works for situations where fragmented packets are allowed through the tunnel without hindrance. For the FTP example, large packets are encapsulated and then fragmented at the IP layer. Intermediate devices may drop fragments or just out-of-order fragments. Load-balancing devices can introduce out-of-order fragments.

When you enable pre-fragmentation, the ASA 1000V fragments tunneled packets that exceed the MTU setting before encapsulating them. If the DF bit on these packets is set, the ASA 1000V clears the DF bit, fragments the packets, and then encapsulates them. This action creates two independent non-fragmented IP packets leaving the public interface and successfully transmits these packets to the peer site by turning the fragments into complete packets to be reassembled at the peer site. In our example, the ASA 1000V overrides the MTU and allows fragmentation by clearing the DF bit.


Note Changing the MTU or the pre-fragmentation option on any interface tears down all existing connections. For example, if 100 active tunnels terminate on the public interface, and you change the MTU or the pre-fragmentation option on the external interface, all of the active tunnels on the public interface are dropped.


Fields

Pre-Fragmentation—Shows the current pre-fragmentation configuration for every configured interface.

Interface—Shows the name of each configured interface.

Pre-Fragmentation Enabled—Shows, for each interface, whether pre-fragmentation is enabled.

DF Bit Policy—Shows the DF Bit Policy for each interface.

Edit—Displays the Edit IPsec Pre-Fragmentation Policy dialog box.

Modes

The following table shows the modes in which this feature is available:

Firewall Mode
Security Context
Routed
Transparent
Single
Multiple
Context
System


Edit IPsec Pre-Fragmentation Policy

Use this pane to modify an existing IPsec pre-fragmentation policy and do-not-fragment (DF) bit policy for an interface selected on the parent pane, Configuration > VPN > IPsec > Pre-Fragmentation

Fields

Interface—Identifies the chosen interface. You cannot change this parameter using this dialog box.

Enable IPsec pre-fragmentation—Enables or disables IPsec pre-fragmentation. The ASA 1000V fragments tunneled packets that exceed the MTU setting before encapsulating them. If the DF bit on these packets is set, the ASA 1000V clears the DF bit, fragments the packets, and then encapsulates them. This action creates two independent, non-fragmented IP packets leaving the public interface and successfully transmits these packets to the peer site by turning the fragments into complete packets to be reassembled at the peer site.

DF Bit Setting Policy—Choose the do-not-fragment bit policy: Copy, Clear, or Set.

Modes

The following table shows the modes in which this feature is available:

Firewall Mode
Security Context
Routed
Transparent
Single
Multiple
Context
System


IPsec Transform Sets

Use this pane to view and add or edit transform sets. A transform is a set of operations done on a data flow to provide data authentication, data confidentiality, and data compression. For example, one transform is the ESP protocol with 3DES encryption and the HMAC-MD5 authentication algorithm (ESP-3DES-MD5).

Fields

IKEv1 IPsec Proposals (Transform Sets)—Shows the configured transform sets.

Name—Shows the name of the transform sets.

Mode—Shows the mode, Tunnel, of the transform set. This parameter specifies the mode for applying ESP encryption and authentication; in other words, what part of the original IP packet has ESP applied. Tunnel mode applies ESP encryption and authentication to the entire original IP packet (IP header and data), thus hiding the ultimate source and destination addresses.

ESP Encryption—Shows the Encapsulating Security Protocol (ESP) encryption algorithms for the transform sets. ESP provides data privacy services, optional data authentication, and anti-replay services. ESP encapsulates the data being protected.

ESP Authentication—Shows the ESP authentication algorithms for the transform sets.

Add—Opens the Add Transform Set dialog box, in which you can add a new transform set.

Edit—Opens the Edit Transform Set dialog box, in which you can modify an existing transform set.

Delete—Removes the selected transform set. There is no confirmation or undo.

IKEv2 IPsec Proposals—Shows the configured transform sets.

Name—Shows the name of the IKEv2 IPsec Proposal.

Encryption—Shows the Encapsulating Security Protocol (ESP) encryption algorithms for the IKEv2 IPsec Proposal. ESP provides data privacy services, optional data authentication, and anti-replay services. ESP encapsulates the data being protected.

Integrity Hash—Shows the hash algorithm that ensures data integrity for the ESP protocol. It ensures that a packet comes from whom you think it comes from, and that it has not been modified in transit.

Add—Opens the Add IPsec Proposal dialog box, in which you can add a new proposal.

Edit—Opens the Edit IPsec Proposal dialog box, in which you can modify an existing proposal.

Delete—Removes the selected proposal. There is no confirmation or undo.

Modes

The following table shows the modes in which this feature is available:

Firewall Mode
Security Context
Routed
Transparent
Single
Multiple
Context
System


Add/Edit IPsec Proposal (Transform Set)

Use this pane to add or modify an IPsec IKEv1 transform set. A transform is a set of operations done on a data flow to provide data authentication, data confidentiality, and data compression. For example, one transform is the ESP protocol with 3DES encryption and the HMAC-MD5 authentication algorithm (ESP-3DES-MD5).

Fields

Set Name—Specifies a name for this transform set.

Properties—Configures properties for this transform set. These properties appear in the Transform Sets table.

Mode—Shows the mode, Tunnel, of the transform set. This field shows the mode for applying ESP encryption and authentication; in other words, what part of the original IP packet has ESP applied. Tunnel mode applies ESP encryption and authentication to the entire original IP packet (IP header and data), thus hiding the ultimate source and destination addresses.

ESP Encryption—Choose the Encapsulating Security Protocol (ESP) encryption algorithms for the transform sets. ESP provides data privacy services, optional data authentication, and anti-replay services. ESP encapsulates the data being protected.

ESP Authentication—Choose the ESP authentication algorithms for the transform sets.


Note The IPsec ESP (Encapsulating Security Payload) protocol provides both encryption and authentication. Packet authentication proves that data comes from whom you think it comes from; it is often referred to as "data integrity."


Modes

The following table shows the modes in which this feature is available:

Firewall Mode
Security Context
Routed
Transparent
Single
Multiple
Context
System


14-32

Add/Edit IPsec Proposal

Use this pane to add or modify an IPsec IKEv2 proposal. A proposal is a set of operations done on a data flow to provide data authentication, data confidentiality, and data compression. For example, one proposal is the ESP protocol with 3DES encryption and the HMAC-MD5 authentication algorithm (ESP-3DES-MD5).

Fields

Name—Specifies a name for this proposal.

Encryption—Choose the Encapsulating Security Protocol (ESP) encryption algorithms for the proposal. ESP provides data privacy services, optional data authentication, and anti-replay services. ESP encapsulates the data being protected.

Integrity Hash—Choose the ESP authentication algorithms for the proposal. The hash algorithm ensures data integrity for the ESP protocol. It ensures that a packet comes from whom you think it comes from, and that it has not been modified in transit.


Note The IPsec ESP (Encapsulating Security Payload) protocol provides both encryption and authentication. Packet authentication proves that data comes from whom you think it comes from; it is often referred to as "data integrity."


Modes

The following table shows the modes in which this feature is available:

Firewall Mode
Security Context
Routed
Transparent
Single
Multiple
Context
System


14-32