ipsec
Configuring IPSec
Table of Contents
Configuring IPSec
Supported Standards
List of Terms
Order in Which You Configure Your IPSec
About IPSec
Access Lists' Compatibility with IPSec
Global Lifetimes for IPSec Security Associations
How These Lifetimes Work
Crypto Access Lists
Crypto Access List Tips
Mirror Image Crypto Access Lists at each IPSec Peer
any Keyword in Crypto Access Lists
Transform Sets
Selecting Appropriate Transforms
Crypto Map Entries
About Crypto Maps
Redundancy
How Many Crypto Maps Should You Create?
Manual Security Associations (Using Pre-Shared Keys)
IKE-Established Security Associations
Dynamic Crypto Maps
Apply Crypto Map Sets to Interface
Monitor and Maintain IPSec
Configuring IPSec
Configuring IPSec with IKE
Configuring Manual IPSec
About IKE
IKE Policies
Why Do You Need to Create These Policies?
What Parameters Do You Define in a Policy?
How Do IKE Peers Agree upon a Matching Policy?
Which Value Should You Select for Each Parameter?
Creating Policies
Additional Configuration Required for IKE Policies
IKE Pre-Shared (Authentication) Keys
Configuring IKE
Enabling and Configuring IKE
Configuring IKE Pre-Shared (Authentication) Keys Manually
Disabling IKE
About Extended Authentication (Xauth)
Making an Exception for Security Gateways
Configuring Extended Authentication
About IKE Mode Config (Dynamic IP Address Assignment for VPN Client)
Benefits
Types
Summary of Tasks
Making an Exception for Security Gateways
Configuring Dynamic IP Addressing Assignment
About CA
IPSec without CAs
IPSec with CAs
How CA Certificates Are Used by IPSec Peers
Registration Authorities
Configuring CA
Configuring IPSec
This chapter provides information about IP Security Protocol (IPSec), Internet Key Exchange (IKE), IKE Mode Configuration (Config), and Certification Authority (CA) features so that you can successfully implement these features into the PIX Firewall and have Virtual Private Network (VPN) capability. This chapter describes the features' functions, as well as how these features interoperate with one another. You will find the applicable configuration steps after each component's "about" section.
This chapter includes the following sections:
Supported Standards
List of Terms
Order in Which You Configure Your IPSec
About IPSec
Configuring IPSec
About IKE
Configuring IKE
About Extended Authentication (Xauth)
Configuring Extended Authentication
About IKE Mode Config (Dynamic IP Address Assignment for VPN Client)
Configuring Dynamic IP Addressing Assignment
About CA
Configuring CA
The IPSec-related commands are listed and described within "Command Reference."
See "Configuration Examples," for additional examples of IPSec configurations.
Supported Standards
Cisco implements the following standards for the IPSec and IKE features within the PIX Firewall:
IPSec—IP Security Protocol. IPSec is a framework of open standards that provides data confidentiality, data integrity, and data authentication between participating peers. IPSec provides these security services at the IP layer; it uses IKE to handle negotiation of protocols and algorithms based on local policy and to generate the encryption and authentication keys to be used by IPSec. IPSec can be used to protect one or more data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.
IPSec is documented in a series of Internet RFCs, all available at http://www.ietf.org/html.charters/ipsec-charter.html. The overall IPSec implementation is guided by "Security Architecture for the Internet Protocol," RFC#2401.
Internet Key Exchange (IKE)—A hybrid protocol that implements Oakley and SKEME key exchanges inside the Internet Security Association and Key Management Protocol (ISAKMP) framework. While IKE can be used with other protocols, its initial implementation is with the IPSec protocol. IKE provides authentication of the IPSec peers, negotiates IPSec security associations, and establishes IPSec keys.
IPSec as implemented in PIX Firewall supports the following additional standards:
AH—Authentication Header. A security protocol that provides data authentication and optional anti-replay services. AH is embedded in the data to be protected (a full IP datagram).
The AH protocol (RFC#2402) allows for the use of various authentication algorithms; PIX Firewall has implemented the mandatory MD5-HMAC (RFC#2403) and SHA-HMAC (RFC#2404) authentication algorithms. Used in conjunction with ISAKMP, the AH protocol algorithms. In conjunction with ISAKMP, the ESP protocol provides anti-replay services.
ESP—Encapsulating Security Payload. A security protocol that provides data privacy services and optional data authentication, and anti-replay services. ESP encapsulates the data to be protected.
The ESP protocol (RFC#2406) allows for the use of various cipher algorithms and (optionally) various authentication algorithms. The PIX Firewall implements the mandatory 56-bit DES-CBC with Explicit IV (RFC#2405); as the encryption algorithm, and MD5-HMAC (RFC#2403) or SHA-HMAC (RFC#2404) as the authentication.
IKE is implemented per "The Internet Key Exchange" (RFC#2409).
ISAKMP—The Internet Security Association and Key Management Protocol. A protocol framework that defines payload formats, the mechanics of implementing a key exchange protocol, and the negotiation of a security association.
ISAKMP is implemented per "Internet Security Association and Key Management Protocol (ISAKMP)" (RFC#2408).
Oakley—A key exchange protocol that defines how to derive authenticated keying material.
Skeme—A key exchange protocol that defines how to derive authenticated keying material, with rapid key refreshment.
The component technologies implemented for use by IKE include:
DES—Data Encryption Standard (DES) is used to encrypt packet data. IKE implements the 56-bit DES-CBC with Explicit IV standard. See "CBC."
Triple DES (3DES)—A variant of DES, which iterates three times with three separate keys, effectively doubling the strength of DES.
CBC—Cipher Block Chaining (CBC) requires an initialization vector (IV) to start encryption. The IV is explicitly given in the IPSec packet.
Diffie-Hellman—A public-key cryptography protocol which allows two parties to establish a shared secret over an unsecure communications channel. Diffie-Hellman is used within IKE to establish session keys. 768-bit and 1024-bit Diffie-Hellman groups are supported.
MD5 (HMAC variant)—MD5 (Message Digest 5) is a hash algorithm used to authenticate packet data. HMAC is a variant which provides an additional level of hashing.
SHA (HMAC variant)—SHA (Secure Hash Algorithm) is a hash algorithm used to authenticate packet data. HMAC is a variant which provides an additional level of hashing.
RSA signatures—RSA is the public key cryptographic system developed by Ron Rivest, Adi Shamir, and Leonard Adleman. RSA signatures provides non-repudiation.
IKE Extended Authentication (Xauth) is implemented per the IETF draft-ietf-ipsec-isakmp-xauth-04.txt ("extended authentication" draft). This provides this capability of authenticating a user within IKE using TACACS+ or Radius.
IKE Configuration Mode is implemented per the IETF draft-ietf-ipsec-isakmp-mode-cfg-04.txt. IKE Configuration Mode provides a method for a security gateway to download an IP address (and other network level configuration) to the VPN client as part of an IKE negotiation.
IKE interoperates with the following standard:
X.509v3 certificates—Used with the IKE protocol when authentication requires public keys. Certificate support that allows the IPSec-protected network to scale by providing the equivalent of a digital ID card to each device. When two peers wish to communicate, they exchange digital certificates to prove their identities (thus removing the need to manually exchange public keys with each peer or to manually specify a shared key at each peer). These certificates are obtained from a CA. X.509 is part of the X.500 standard by the ITU.
CA supports the following standards:
X.509v3 certificates
Public-Key Cryptography Standard #7 (PKCS #7)—A standard from RSA Data Security, Inc. used to encrypt and sign certificate enrollment messages.
Public-Key Cryptography Standard #10 (PKCS #10)—A standard syntax from RSA Data Security, Inc. for certificate requests.
RSA Keys—RSA is the public key cryptographic system developed by Ron Rivest, Adi Shamir, and Leonard Adleman. RSA keys come in pairs: one public key and one private key.
List of Terms
anti-replay—A security service where the receiver can reject old or duplicate packets to protect itself against replay attacks. IPSec provides this optional service by use of a sequence number combined with the use of data authentication. PIX Firewall IPSec provides this service whenever it provides the data authentication service, except in the following case:
The service is not available for manually established security associations (that is, security associations established by manual configuration and not by IKE).
Certification Authority (CA)—CAs are responsible for managing digital certificate requests and issuing digital certificates to participating IPSec network peers. These services provide centralized key management for the participating peers.
Certificate Revocation List (CRL)—A method certificate revocation. A CRL is a time stamped list identifying revoked certificates, which is signed by a CA and made available to the participating IPSec peers on a regular periodic basis (for example, hourly, daily, or weekly). Each revoked certificate is identified in a CRL by its certificate serial number. When a participating peer device uses a certificate, that system not only checks the certificate signature and validity but also acquires a most recently issued CRL and checks that the certificate serial number is not on that CRL.
data authentication—Includes two concepts:
Data integrity (verify that data has not been altered).
Data origin authentication (verify that the data was actually sent by the claimed sender).
Data authentication can refer either to integrity alone or to both of these concepts (although data origin authentication is dependent upon data integrity).
data confidentiality—A security service where the protected data cannot be observed.
data flow—A grouping of traffic, identified by a combination of source address/netmask, destination address/netmask, IP next protocol field, and source and destination ports, where the protocol and port fields can have the values of any. In effect, all traffic matching a specific combination of these values is logically grouped together into a data flow. A data flow can represent a single TCP connection between two hosts, or it can represent all traffic between two subnets. IPSec protection is applied to data flows.
IPSec client—An IPSec host that establishes IPSec tunnel(s) between itself and a Security gateway/IPSec client to protect traffic for itself.
peer—In the context of this chapter, a peer refers to a PIX Firewall or other device, such as a Cisco router, that participates in IPSec, IKE, and CA.
perfect forward secrecy (PFS)—A cryptographic characteristic associated with a derived shared secret value. With PFS, if one key is compromised, previous and subsequent keys are not compromised, because subsequent keys are not derived from previous keys.
repudiation—A quality that prevents a third party from being able to prove that a communication between two other parties ever took place. This is a desirable quality if you do not want your communications to be traceable. Non-repudiation is the opposite quality—a third party can prove that a communication between two other parties took place. Non-repudiation is desirable if you want to be able to trace your communications and prove that they occurred.
security association—An IPSec security association (SA) is a description of how two or more entities will use security services in the context of a particular security protocol (AH or ESP) to communicate securely on behalf of a particular data flow. It includes such things as the transform and the shared secret keys to be used for protecting the traffic.
The IPSec security association is established either by IKE or by manual user configuration. Security associations are uni-directional and are unique per security protocol. So when security associations are established for IPSec, the security associations (for each protocol) for both directions are established at the same time.
When using IKE to establish the security associations for the data flow, the security associations are established when needed and expire after a period of time (or volume of traffic). If the security associations are manually established, they are established as soon as the necessary configuration is completed and do not expire.
security gateway—A security gateway is an intermediate system that acts as the communications interface between two networks. The set of hosts (and networks) on the external side of the security gateway is viewed as untrusted (or less trusted), while the networks and hosts and on the internal side are viewed as trusted (or more trusted). The internal subnets and hosts served by a security gateway are presumed to be trusted by virtue of sharing a common, local, security administration.
In the IPSec context, a security gateway is a point at which AH and/or ESP is implemented to serve a set of internal hosts, providing security services for these hosts when they communicate with external hosts also employing IPSec (either directly or via another security gateway).
Security parameter index (SPI)—This is a number which, together with a destination IP address and security protocol, uniquely identifies a particular security association. When using IKE to establish the security associations, the SPI for each security association is a pseudo-randomly derived number. Without IKE, the SPI is manually specified for each security association.
transform—A transform lists a security protocol (AH or ESP) with its corresponding algorithms. For example, one transform is the AH protocol with the MD5-HMAC authentication algorithm; another transform is the ESP protocol with the 56-bit DES encryption algorithm and the SHA-HMAC authentication algorithm.
tunnel—In the context of this chapter, a tunnel refers to a secure communication path between two peers, such as two PIX Firewall units. It does not refer to using IPSec in tunnel mode.
Virtual Private Network (VPN)—Enables IP traffic to travel securely over a public TCP/IP network by encrypting all traffic from one network to another. A VPN uses "tunneling" to encrypt all information at the IP level.
Order in Which You Configure Your IPSec
If you will implement interoperability with a CA, Cisco recommends that you perform your IPSec configuration in the following order:
1. CA (see "Configuring CA")
2. IKE (see "Configuring IKE")
3. IPSec (see "Configuring IPSec")
4. (Optional) IKE Extended Authentication—applies only if you are configuring user authentication for remote VPN clients (see "Configuring Extended Authentication")
5. (Optional) IKE Mode Configuration—applies only if you are configuring dynamic IP addressing for remote VPN clients (see "Configuring Dynamic IP Addressing Assignment")
If you will not implement interoperability with a CA, and you will implement IKE, Cisco recommends that you perform your IPSec configuration in the following order:
1. IKE (see "Configuring IKE")
2. IPSec (see "Configuring IPSec")
3. (Optional) IKE Extended Authentication—applies only if you are configuring user authentication for remote VPN clients (see "Configuring Extended Authentication")
4. (Optional) IKE Mode Configuration—applies only if you are configuring dynamic IP addressing for remote VPN clients (see "Configuring Dynamic IP Addressing Assignment")
If you will not implement IKE, see "Configuring IPSec."
About IPSec
IPSec provides security for transmission of sensitive information over unprotected networks such as the Internet. IPSec acts at the network layer, protecting and authenticating IP packets between participating IPSec devices (peers), such as PIX Firewall units.
With IPSec, data can be transmitted across a public network without fear of observation, modification, or spoofing. This enables applications such as VPNs, which are categorized by intranets, extranets, and remote dial access. Each VPN type has different security service needs.With VPN, customers, business partners, and remote users, such as telecommuters, can access enterprise computing resources securely. VPNs essentially extend a network's capability by accommodating the demands of a networked economy for diverse secured connectivity.
IPSec provides the following network security services. These services are optional. In general, a local security policy will dictate the use of one or more of these services:
Data Confidentiality—The IPSec sender can encrypt packets before transmitting them across a network.
Data Integrity—The IPSec receiver can authenticate packets sent by the IPSec sender to ensure that the data has not been altered during transmission.
Data Origin Authentication—The IPSec receiver can authenticate the source of the IPSec packets sent. This service is dependent upon the data integrity service.
Anti-Replay—The IPSec receiver can detect and reject replayed packets.
Note The term data authentication is generally used to mean data integrity and data origin
authentication. Within this chapter, it also includes anti-replay services, unless otherwise
specified.
In simple terms, IPSec provides secure tunnels between two peers, such as two PIX Firewall units. You define which packets are considered sensitive and should be sent through these secure tunnels, and you define the parameters that should be used to protect these sensitive packets, by specifying the characteristics of these tunnels. Then, when the IPSec peer sees such a sensitive packet, it sets up the appropriate secure tunnel and sends the packet through the tunnel to the remote peer.
More accurately, these tunnels are sets of security associations that are established between two remote IPSec peers. The security associations define which protocols and algorithms should be applied to sensitive packets, and also specify the keying material to be used by the two peers. Security associations are uni-directional and are established per security protocol (AH or ESP).
With IPSec, you define what traffic should be protected between two remote IPSec peers by configuring access lists and applying these access lists to interfaces by way of crypto map sets. Therefore, traffic may be selected on the basis of source and destination address. (Access lists used for IPSec are used only to determine which traffic should be protected by IPSec, not which traffic should be blocked or permitted through the interface. Separate access lists define blocking and permitting at the interface or inbound and outbound from the PIX Firewall.)
A crypto map set can contain multiple entries, each with a different access list. The crypto map entries are searched in order—the PIX Firewall attempts to match the packet to the access list specified in that entry.
When a packet matches a permit entry in a particular access list, and the corresponding crypto map entry is tagged as ipsec-isakmp, IPSec is triggered.
If no security association exists that IPSec can use to protect this traffic to the peer, IPSec uses IKE to negotiate with the peer to set up the necessary IPSec security associations on behalf of the data flow. The negotiation uses information specified in the crypto map entry as well as the data flow information from the specific access list entry. (The behavior is different for dynamic crypto map entries. Refer to "Dynamic Crypto Maps.")
If the crypto map entry is tagged as ipsec-manual, IPSec is triggered. If no security association exists that IPSec can use to protect this traffic to the peer, the traffic is dropped. In this case, the security associations are installed via the configuration, without the intervention of IKE. If the security associations did not exist, IPSec did not have all the necessary pieces configured.
Once established, the set of security associations (outbound, to the remote peer) is then applied to the triggering packet as well as to subsequent applicable packets as those packets exit the PIX Firewall. "Applicable" packets are packets that match the same access list criteria that the original packet matched. For example, all applicable packets could be encrypted before being forwarded to the remote peer. The corresponding inbound security associations are used when processing the incoming traffic from that peer.
If IKE is used to establish the security associations, the security associations will have lifetimes so that they will periodically expire and require renegotiation. (This provides an additional level of security.)
Multiple IPSec tunnels can exist between two peers to secure different data streams, with each tunnel using a separate set of security associations. For example, some data streams might be just authenticated while other data streams must be both encrypted and authenticated.
Access lists associated with IPSec crypto map entries also represent which traffic the PIX Firewall requires to be protected by IPSec. Inbound traffic is processed against the crypto map entries—if an unprotected packet matches a permit entry in a particular access list associated with an IPSec crypto map entry, that packet is dropped because it was not sent as an IPSec-protected packet.
Crypto map entries also include transform sets. A transform set is an acceptable combination of security protocols, algorithms, and other settings to apply to IPSec-protected traffic. During the IPSec security association negotiation, the peers agree to use a particular transform set when protecting a particular data flow.
This section includes the following topics, which provides more IPSec background information you will need to know prior to configuring IPSec. The steps for configuring IPSec are covered in the section "Configuring IPSec."
Access Lists' Compatibility with IPSec
Global Lifetimes for IPSec Security Associations
Crypto Access Lists
Transform Sets
Crypto Map Entries
Apply Crypto Map Sets to Interface
Monitor and Maintain IPSec
Access Lists' Compatibility with IPSec
By default, IPSec and all packets that traverse the PIX Firewall are subjected to blocking as specified by inbound conduit, outbound list or interface access-list. To enable IPSec packets to traverse the PIX Firewall, ensure that you have statements in conduits, outbound lists or interface access-lists that permit the packets. Optionally, the sysopt connection permit-ipsec command can be configured to enable IPSec packets to bypass the conduit, outbound list and interface access-list blocking.
Note The sysopt connection permit-ipsec command enables packets that have been processed
by IPSec to bypass the conduit, outbound list, and interface access-list checks. destined to
and arriving from an IPSec tunnel to bypass the conduit, outbound list, and interface
access-list checks.
Note IPSec packets that are destined to an IPSec tunnel are selected by the crypto map
access-list bound to the outgoing interface. IPSec packets that arrive from an IPSec tunnel
are authenticated/deciphered by IPSec and subjected to the proxy identity match of the
tunnel.
Global Lifetimes for IPSec Security Associations
You can change the global lifetime values that are used when negotiating new IPSec security associations. (These global lifetime values can be overridden for a particular crypto map entry.)
These lifetimes only apply to security associations established via IKE. Manually established security associations do not expire.
There are two lifetimes: a "timed" lifetime and a "traffic-volume" lifetime. A security association expires after the respective lifetime is reached and negotiations will be initiated for a new one. The default lifetimes are 28,800 seconds (eight hours) and 4,608,000 kilobytes (10 megabytes per second for one hour).
If you change a global lifetime, the new lifetime value will not be applied to currently existing security associations, but will be used in the negotiation of subsequently established security associations. If you wish to use the new values immediately, you can clear all or part of the security association database. See the clear [crypto] ipsec sa command for more information within the crypto ipsec command page of "Command Reference."
IPSec security associations use one or more shared secret keys. These keys and their security associations time out together.
How These Lifetimes Work
Assuming that the particular crypto map entry does not have lifetime values configured, when the PIX Firewall requests new security associations it will specify its global lifetime values in the request to the peer; it will use this value as the lifetime of the new security associations. When the PIX Firewall receives a negotiation request from the peer, it will use the smaller of either the lifetime value proposed by the peer or the locally configured lifetime value as the lifetime of the new security associations.
The security association (and corresponding keys) will expire according to whichever occurs sooner, either after the seconds timeout or after the kilobytes amount of traffic is passed.
A new security association is negotiated before the lifetime threshold of the existing security association is reached to ensure that a new security association is ready for use when the old one expires. The new security association is negotiated either 30 seconds before the seconds lifetime expires or when the volume of traffic through the tunnel reaches 256 kilobytes less than the kilobytes lifetime (whichever occurs first).
If no traffic has passed through the tunnel during the entire life of the security association, a new security association is not negotiated when the lifetime expires. Instead, a new security association will be negotiated only when IPSec sees another packet that should be protected.
Crypto Access Lists
Crypto access lists are used to define which IP traffic will be protected by crypto and which traffic will not be protected by crypto. For example, access lists can be created to protect all IP traffic between Subnet A and Subnet Y or between Host A and Host B. (These access lists are similar to access lists used with the access-group command. With the access-group command, the access-list determines which traffic to forward or block at an interface.)
The access lists themselves are not specific to IPSec. It is the crypto map entry referencing the specific access list that defines whether IPSec processing is applied to the traffic matching a permit in the access list.
Crypto access lists associated with IPSec crypto map entries have four primary functions:
Select outbound traffic to be protected by IPSec (permit = protect).
Indicate the data flow to be protected by the new security associations (specified by a single permit entry) when initiating negotiations for IPSec security associations.
Process inbound traffic to filter out and discard traffic that should have been protected by IPSec.
Determine whether or not to accept requests for IPSec security associations on behalf of the requested data flows when processing IKE negotiation from the peer. (Negotiation is only done for ipsec-isakmp crypto map entries.) In order for the peer's request to be accepted during negotiation, the peer must specify a data flow that is "permitted" by a crypto access list associated with an ipsec-isakmp crypto map command entry.
If you want certain traffic to receive one combination of IPSec protection (for example, authentication only) and other traffic to receive a different combination of IPSec protection (for example, both authentication and encryption), you need to create two different crypto access lists to define the two different types of traffic. These different access lists are then used in different crypto map entries which specify different IPSec policies.
This section includes the following topics:
Crypto Access List Tips
Mirror Image Crypto Access Lists at each IPSec Peer
any Keyword in Crypto Access Lists
Crypto Access List Tips
Using the permit keyword causes all IP traffic that matches the specified conditions to be protected by crypto, using the policy described by the corresponding crypto map entry. Using the deny keyword prevents traffic from being protected by crypto IPSec in the context of that particular crypto map entry. (In other words, it does not allow the policy as specified in this crypto map entry to be applied to this traffic.) If this traffic is denied in all the crypto map entries for that interface, the traffic is not protected by crypto IPSec.
The crypto access list you define will be applied to an interface after you define the corresponding crypto map entry and apply the crypto map set to the interface. Different access lists must be used in different entries of the same crypto map set. However, both inbound and outbound traffic will be evaluated against the same "outbound" IPSec access list.
Therefore, the access list's criteria are applied in the forward direction to traffic exiting your PIX Firewall, and the reverse direction to traffic entering your PIX Firewall. In Figure 4-1, IPSec protection is applied to traffic between Host 10.0.0.1 and Host 10.2.2.2 as the data exits PIX Firewall A's outside interface en route to Host 10.2.2.2. For traffic from Host 10.0.0.1 to Host 10.2.2.2, the access list entry on PIX Firewall A is evaluated as follows:
source = host 10.0.0.1
dest = host 10.2.2.2
For traffic from Host 10.2.2.2 to Host 10.0.0.1, that same access list entry on PIX Firewall A is evaluated as follows:
source = host 10.2.2.2
dest = host 10.0.0.1
Figure 4-1: How Crypto Access Lists Are Applied for Processing IPSec
If you configure multiple statements for a given crypto access list that is used for IPSec, in general the first permit statement that is matched will be the statement used to determine the scope of the IPSec security association. That is, the IPSec security association will be set up to protect traffic that meets the criteria of the matched statement only. Later, if traffic matches a different permit statement of the crypto access list, a new, separate IPSec security association will be negotiated to protect traffic matching the newly matched access list statement.
Note Access lists for crypto map entries tagged as ipsec-manual are restricted to a single permit
entry and subsequent entries are ignored. In other words, the security associations
established by that particular crypto map entry are only for a single data flow. To support
multiple manually established security associations for different kinds of traffic, define
multiple crypto access lists, and apply each one to a separate ipsec-manual crypto map
command entry. Each access list should include one permit statement defining which
traffic to protect.
Any unprotected inbound traffic that matches a permit entry in the crypto access list for a crypto map entry flagged as IPSec will be dropped because this traffic was expected to be protected by IPSec.
Note If you clear or delete the last element from an access list, the crypto map references to the
destroyed access list are also removed.
Note If you modify an access list that is currently referenced by one or more crypto map entries,
the run-time security association database will need to be re initialized using the
crypto map interface command. See the
crypto ipsec command
page for information on the crypto map interface command.
Mirror Image Crypto Access Lists at each IPSec Peer
Cisco recommends that for every crypto access list specified for a static crypto map entry that you define at the local peer, you define a "mirror image" crypto access list at the remote peer. This ensures that traffic that has IPSec protection applied locally can be processed correctly at the remote peer. (The crypto map entries themselves must also support common transforms and must refer to the other system as a peer.)
any Keyword in Crypto Access Lists
When you create crypto access lists, using the any keyword could cause problems. Cisco discourages the use of the any keyword to specify source or destination addresses.
The permit any any statement is strongly discouraged, as this will cause all outbound traffic to be protected (and all protected traffic sent to the peer specified in the corresponding crypto map entry) and will require protection for all inbound traffic. Then, all inbound packets that lack IPSec protection will be silently dropped.
You need to be sure you define which packets to protect. If you must use the any keyword in a permit statement, you must preface that statement with a series of deny statements to filter out any traffic (that would otherwise fall within that permit statement) that you do not want to be protected.
Transform Sets
A transform set represents a certain combination of security protocols and algorithms. During the IPSec security association negotiation, the peers agree to use a particular transform set for protecting a particular data flow.
You can specify multiple transform sets, and then specify one or more of these transform sets in a crypto map entry. The transform set defined in the crypto map entry will be used in the IPSec security association negotiation to protect the data flows specified by that crypto map entry's access list.
During IPSec security association negotiations with IKE, the peers search for a transform set that is the same at both peers. When such a transform set is found, it is selected and will be applied to the protected traffic as part of both peers' IPSec security associations.
With manually established security associations, there is no negotiation with the peer, so both sides must specify the same transform set.
If you change a transform set definition, the change is only applied to crypto map entries that reference the transform set. The change will not be applied to existing security associations, but will be used in subsequent negotiations to establish new security associations.
If you want the new settings to take effect sooner, you can clear all or part of the security association database by using the clear [crypto] ipsec sa command. See the clear [crypto] ipsec sa command for more information within the crypto ipsec command page of "Command Reference."
Selecting Appropriate Transforms
Choosing IPSec transforms combination can be complex. The following tips may help you select transforms that are appropriate for your situation:
To provide data confidentiality, include an ESP encryption transform. Also consider including an ESP authentication transform or an AH transform to provide authentication services for the transform set.
To ensure data authentication for the outer IP header as well as the data, include an AH transform.
To ensure data authentication (using either ESP or AH) you can choose from the MD5 or SHA (HMAC keyed hash variants) authentication algorithms. The SHA algorithm is generally considered stronger than MD5, but it is slower.
Note Some transforms may not be supported by the peer.
Suggested transform combinations:
esp-3des and esp-sha-hmac
esp-des and esp-sha-hmac
Crypto Map Entries
To create crypto map entries, follow the guidelines provided in the following sections:
About Crypto Maps
Redundancy
How Many Crypto Maps Should You Create?
Manual Security Associations (Using Pre-Shared Keys)
IKE-Established Security Associations
Dynamic Crypto Maps
About Crypto Maps
Crypto maps specify IPSec policy. Crypto map entries created for IPSec pull together the various parts used to set up IPSec security associations, including the following:
Which traffic should be protected by IPSec (per a crypto access list)
Where IPSec-protected traffic should be sent (who the peer is)
The local address to be used for the IPSec traffic (See the "Apply Crypto Map Sets to Interface" section for more details.)
What IPSec security should be applied to this traffic (selecting from a list of one or more transform sets)
Whether security associations are manually established or are established via IKE
Other parameters that might be necessary to define an IPSec SA
Crypto map entries with the same crypto map name (but different map sequence numbers) are grouped into a crypto map set. Later, you will apply these crypto map sets to interfaces; then, all IP traffic passing through the interface is evaluated against the applied crypto map set. If a crypto map entry sees outbound IP traffic that should be protected and the crypto map specifies the use of IKE, a security association is negotiated with the peer according to the parameters included in the crypto map entry; otherwise, if the crypto map entry specifies the use of manual security associations, a security association should have already been established via configuration. (If a dynamic crypto map entry sees outbound traffic that should be protected and no security association exists, the packet is dropped.)
The policy described in the crypto map entries is used during the negotiation of security associations. If the local PIX Firewall initiates the negotiation, it will use the policy specified in the static crypto map entries to create the offer to be sent to the specified peer. If the peer initiates the negotiation, the PIX Firewall will check the policy from the static crypto map entries, as well as any referenced dynamic crypto map entries to decide whether to accept or reject the peer's request (offer).
For IPSec to succeed between two peers, both peers' crypto map entries must contain compatible configuration statements.
When two peers try to establish a security association, they must each have at least one crypto map entry that is compatible with one of the other peer's crypto map entries. For two crypto map entries to be compatible, they must at a minimum meet the following criteria:
The crypto map entries must contain compatible crypto access lists (for example, mirror image access lists). In the case where the responding peer is using dynamic crypto maps, the entries in the PIX Firewall crypto access list must be "permitted" by the peer's crypto access list.
The crypto map entries must each identify the other peer (unless the responding peer is using dynamic crypto maps).
The crypto map entries must have at least one transform set in common.
Redundancy
You can define multiple peers by using crypto maps to allow for redundancy. If one peer fails, there will still be a protected path. The peer that packets are actually sent to is determined by the last peer that the PIX Firewall heard from (received either traffic or a negotiation request from) for a given data flow. If the attempt fails with the first peer, IKE tries the next peer on the crypto map list.
If you are not sure how to configure each crypto map parameter to guarantee compatibility with other peers, you might consider configuring dynamic crypto maps as described in the section "Dynamic Crypto Maps." Dynamic crypto maps are useful when the establishment of the IPSec tunnels is initiated by the peer. They are not useful if the establishment of the IPSec tunnels is locally initiated, because the dynamic crypto maps are policy templates, not complete statements of policy. (Although the access lists in any referenced dynamic crypto map entry are used for crypto packet filtering.)
How Many Crypto Maps Should You Create?
You can apply only one crypto map set to a single interface. The crypto map set can include a combination of IPSec/IKE and IPSec/manual entries.
If you create more than one crypto map entry for a given interface, use the seq-num of each map entry to rank the map entries: the lower the seq-num, the higher the priority. At the interface that has the crypto map set, traffic is evaluated against higher priority map entries first.
You must create multiple crypto map entries for a given PIX Firewall interface, if any of the following conditions exist:
If different data flows are to be handled by separate peers.
If you want to apply different IPSec security to different types of traffic (to the same or separate peers); for example, if you want traffic between one set of subnets to be authenticated, and traffic between another set of subnets to be both authenticated and encrypted. In this case the different types of traffic should have been defined in two separate access lists, and you must create a separate crypto map entry for each crypto access list.
If you are not using IKE to establish a particular set of IPSec security associations, and want to specify multiple access list entries, you must create separate access lists (one per permit entry) and specify a separate crypto map entry for each access list.
Manual Security Associations (Using Pre-Shared Keys)
The use of manual IPSec security associations is a result of a prior arrangement between the users of the PIX Firewall and its peer. There is no negotiation of security associations, so the configuration information in both systems must be the same for traffic to be processed successfully by IPSec.
The PIX Firewall can simultaneously support manual and IKE-established security associations, even within a single crypto map set.
IKE-Established Security Associations
When IKE is used to establish IPSec security associations, the peers can negotiate the settings they will use for the new security associations. This means that you can specify lists (such as lists of acceptable transforms) within the crypto map entry.
Dynamic Crypto Maps
Dynamic crypto maps (this requires IKE) can ease IPSec configuration and are recommended for use with networks where the peers are not always predetermined. An example of this is mobile users (VPN clients), who obtain dynamically assigned IP addresses. First, the mobile clients need to authenticate themselves to the local PIX Firewall IKE by something other than an IP address, such as a fully qualified domain name. Once authenticated, the security association request can be processed against a dynamic crypto map that is set up to accept requests (matching the specified local policy) from previously unknown peers.
Dynamic crypto maps are only available for use by IKE.
A dynamic crypto map entry is essentially a crypto map entry without all the parameters configured. It acts as a policy template where the missing parameters are later dynamically configured (as the result of an IPSec negotiation) to match a peer's requirements. This allows peers to exchange IPSec traffic with the PIX Firewall even if the PIX Firewall does not have a crypto map entry specifically configured to meet all the peer's requirements.
Note Only the transform-set field is required to be configured within each dynamic crypto map
entry.
Dynamic crypto maps are not used by the PIX Firewall to initiate new IPSec security associations with peers. Dynamic crypto maps are used when a peer tries to initiate an IPSec security association with the PIX Firewall. Dynamic crypto maps are also used in evaluating traffic.
A dynamic crypto map set is included by reference as part of a crypto map set. Any crypto map entries that reference dynamic crypto map sets should be the lowest priority crypto map entries in the crypto map set (that is, have the highest sequence numbers) so that the other crypto map entries are evaluated first; that way, the dynamic crypto map set is examined only when the other (static) map entries are not successfully matched.
If the PIX Firewall accepts the peer's request, at the point that it installs the new IPSec security associations it also installs a temporary crypto map entry. This entry is filled in with the results of the negotiation. At this point, the PIX Firewall performs normal processing, using this temporary crypto map entry as a normal entry, even requesting new security associations if the current ones are expiring (based upon the policy specified in the temporary crypto map entry). Once the flow expires (that is, all the corresponding security associations expire), the temporary crypto map entry is then removed.
For both static and dynamic crypto maps, if unprotected inbound traffic matches a permit statement in an access list, and the corresponding crypto map entry is tagged as "IPSec," the traffic is dropped because it is not IPSec protected. (This is because the security policy as specified by the crypto map entry states that this traffic must be IPSec protected.)
For static crypto map entries, if outbound traffic matches a permit statement in an access list and the corresponding security association is not yet established, the PIX Firewall will initiate new security associations with the peer. In the case of dynamic crypto map entries, if no security association existed, the traffic would simply be dropped (because dynamic crypto maps are not used for initiating new security associations).
Note Use care when using the any keyword in permit entries in dynamic crypto maps. If it is
possible for the traffic covered by such a permit entry to include multicast or broadcast
traffic, the access list should include deny entries for the appropriate address range. Access
lists should also include deny entries for network and subnet broadcast traffic, and for any
other traffic that should not be IPSec protected.
Dynamic Crypto Map Set
Dynamic crypto map entries, like regular static crypto map entries, are grouped into sets. A set is a group of dynamic crypto map entries all with the same dynamic-map-name but each with a different dynamic-seq-num.
If this is configured, the data flow identity proposed by the IPSec peer must fall within a permit statement for this crypto access list.
If this is not configured, the PIX Firewall will accept any data flow identity proposed by the peer.
Care must be taken if the any keyword is used in the access list, because the access list is used for packet filtering, as well as for negotiation.
Dynamic crypto map entries specify crypto access lists that limit traffic for which IPSec security associations can be established. A dynamic crypto map entry that does not specify an access list will be ignored during traffic filtering. If there is only one dynamic crypto map entry in the crypto map set, it must specify acceptable transform sets.
Add the Dynamic Crypto Map Set into a Regular (Static) Crypto Map Set
You can add one or more dynamic crypto map sets into a crypto map set via crypto map entries that reference the dynamic crypto map sets. You should set the crypto map entries referencing dynamic maps to be the lowest priority entries in a crypto map set (that is, use the highest sequence numbers).
Apply Crypto Map Sets to Interface
You need to apply a crypto map set to each interface through which IPSec traffic will flow. The PIX Firewall supports IPSec on all of it's interfaces. Applying the crypto map set to an interface instructs the PIX Firewall to evaluate all the interface's traffic against the crypto map set and to use the specified policy during connection or security association negotiation on behalf of traffic to be protected by crypto IPSec.
Note Binding a crypto map to an interface will also initialize the run-time data structures, such
as the security association database and the security policy database. If the crypto map is
modified in any significant manner, reapplying the crypto map to the interface will
resynchronize the various run-time data structures with the crypto map configuration.
Monitor and Maintain IPSec
Certain configuration changes will only take effect when negotiating subsequent security associations. If you want the new settings to take immediate effect, you must clear the existing security associations so that they will be re-established with the changed configuration. For manually established security associations, you must clear and reinitialize the security associations or the changes will never take effect. If the PIX Firewall is actively processing IPSec traffic, it is desirable to clear only the portion of the security association database that would be affected by the configuration changes (that is, clear only the security associations established by a given crypto map set). Clearing the full security association database should be reserved for large-scale changes, or when the PIX Firewall is processing a small number of other IPSec traffic.
Table 4-1 lists commands you can use to clear and reinitialize IPSec security associations.
Table 4-1: Commands to Clear and Reinitialize IPSec SAs
Command
Purpose
crypto map map-name interface interface-name
Reinitalize the IPSec run-time security association database and security policy database.
clear [crypto] ipsec sa
or
clear [crypto] ipsec sa peer ip-address | peer-name
or
clear [crypto] ipsec sa map map-name
or
clear [crypto] ipsec sa entry destination-address protocol spi
Clear IPSec security associations.
Note Using the clear [crypto] ipsec sa command without parameters will clear out the full security association database, which will clear out active security sessions. You may also specify the peer, map, or entry keywords to clear out only a subset of the security association database. For more information, see the clear [crypto] ipsec sa command within "Command Reference."
Table 4-2 lists commands you can use to view information about your IPSec configuration.
Table 4-2: Commands to View IPSec Configuration Information
Command
Purpose
shoразделы
оркестр креольский танго
создание анимационный клип
лотерея
сэндвич кофе-бар
dunlup 205 55 r16
бегущий строка
сушильный машина electrolux
metrobond
фарфор portofino
вилатерм
срочный перевод
автобетононасосы
химчистка доставка
кофе колониальный товар
lida
химчистка доставка
гипсокартон
краска двухкомпонентный
клеить 88 люкс
дюпон краска
девелоперская компания
грунт
электрокамин dimplex model silver (sp4)
рак простата
центральный детский мир
ipsec