IPSec Configuration Tasks
IPSec Configuration Tasks
Configuring IPSec has four major tasks, which are
-
Task 1: Prepare to configure VPN support.
-
Task 2: Configure IKE parameters.
-
Task 3: Configure IPSec parameters.
-
Task 4: Test and verify VPN configuration.
Each of these tasks requires several steps. The following sections look at each of these configuration tasks in greater detail.
Task 1: Prepare to Configure VPN Support
This task consists of several steps to determine IKE and IPSec policies, ensure the network works before encryption, and ensure the PIX Firewall can support IPSec. Successful implementation of an IPSec network requires advance preparation before beginning configuration of individual devices.
Configuring IPSec encryption can be complicated and, at times, confusing. To reduce both, it’s essential to plan ahead. If you get in a hurry, this can only lead to lost time and frustration. Because this process was defined in detail in Chapter 10, it won’t be repeated here. Follow these basic planning steps:
Step 1.1: Determine IKE (IKE Phase one) policy to be used between IPSec peers, including whether to use preshared keys or CAs.
Step 1.2: Determine IPSec (IKE Phase two) policy, including the IPSec peer details, such as IP addresses and IPSec modes to be used when configuring the crypto maps.
Step 1.3: Check the current configuration to see if IPSec is currently being used on the devices. Use the write terminal, show isakmp [policy], show crypto map, and other show commands covered later in this chapter.
Step 1.4: Verify the network works without encryption. Verify basic connectivity among all devices with the ping command.
| Note? |
All Cisco documentation includes this step, but it seems this should be Step 1. Without basic connectivity, the rest is just spinning your wheels. Consider it in “real world” implementations. |
Step 1.5: Make sure any access lists are compatible with IPSec. Verify perimeter routers and the PIX Firewall outside interfaces permit IPSec traffic. Implicitly permit IPSec packets to bypass PIX Firewall access lists and conduits. Use the show access-lists command.
| Note? |
As you learned in the VPN chapters, there might only be four or five major tasks, but each task can have a similar number of steps. To make this easier to track, we’ll again use a decimal notation to link tasks, steps, and substeps. For example, Step 1.5 indicates Task 1 Step 5. If Step 1.5 had multiple parts, they would be noted by a second decimal (Step 1.5.3). |
Task 2: Configure IKE Parameters
The second major task in configuring the PIX Firewall is to configure the IKE parameters developed in Task 1. This task involves several steps to make sure IKE can establish secure channels to the appropriate IPSec peers. Only after this process is successfully completed can IKE set up the IPSec SAs that allow IPSec data exchanges. Configuring the IKE parameters involves the following four steps:
-
Step 2.1: Enable or disable IKE.
-
Step 2.2: Create IKE policies.
-
Step 2.3: Configure preshared keys.
-
Step 2.4: Verify IKE configuration.
Step 2.1 Enable or Disable IKE
The isakmp enable command is used to enable ISAKMP negotiation on an interface on which the IPSec peer communicates with the PIX Firewall. ISAKMP is enabled by default. Use the no form of the command to disable IKE. The syntax and an example are as follows:
Pix(config)# isakmp enable interface-name Pix(config)# no isakmp enable interface-name Pix(config)# no isakmp enable inside
PIX Firewall version 5.0 software supported IPSec termination on the outside interface only. Since version 5.1, the PIX Firewall supports IPSec termination on any interface. A good practice is to disable IKE on interfaces that don’t terminate IKE and IPSec to prevent possible denial-of-service attacks on those interfaces.
Step 2.2 Create IKE Policies
To define an IKE policy to be used instead of the default settings, use a unique priority number. Priority numbers are integers between 1 and 65,534, with 1 as the highest priority and 65,534 as the lowest. The priority number is used with up to five isakmp policy priority commands. If one of the isakmp policy commands isn’t configured, then the default value is assumed. Use the no isakmp policy priority command to remove the entire policy from the configuration. To enable and configure IKE, perform the following steps.
Specify Encryption Algorithm
Use the configuration mode isakmp policy priority encryption command to specify the encryption algorithm. The no isakmp policy priority encryption command resets the encryption algorithm to the default value, DES. The syntax and an example are as follows:
Pix(config)# isakmp policy priority encryption {des | 3des}
Pix(config)# isakmp policy 100 encryption des
Specify the Hash Algorithm
Use the configuration mode isakmp policy priority hash command to specify the hash algorithm. The no isakmp policy priority hash command resets the hash algorithm to the default value of SHA-1. The syntax and an example are as follows:
Pix(config)# isakmp policy priority hash {md5 | sha}
Pix(config)# isakmp policy 100 hash md5
Specify Authentication Method
Use the configuration mode isakmp policy priority authentication command to specify the authentication method. The no isakmp policy priority authentication command resets the authentication method to the default value of RSA signatures. The syntax and an example are as follows:
Pix(config)# isakmp policy priority authentication {pre-share | rsa-sig}
Pix(config)# isakmp policy 100 authentication rsa-sig
With RSA signatures, configuring the PIX Firewall and its peer to obtain certificates from a CA is necessary. With preshared keys, the preshared keys must be configured on both the PIX Firewall and the peer. See Step 2.3, Configuring Authentication Method, in this chapter.
Specify Diffie–Hellman Group
Use the configuration mode isakmp policy priority group command to specify the Diffie–Hellman group to be used in an IKE policy. The 1,024-bit Diffie–Hellman (Group 2) provides stronger security, but requires greater CPU resources. The no isakmp policy priority group command resets the Diffie–Hellman group identifier to the default value of group 1 (768-bit Diffie–Hellman). The syntax and an example are as follows:
Pix(config)# isakmp policy priority group {1 | 2}
Pix(config)# isakmp policy 100 group 2
The new Cisco VPN Client version 3.x for remote access uses Diffie–Hellman group 2.
Specify Security Association’s Lifetime
Use the configuration mode isakmp policy priority lifetime command to specify the security association’s lifetime. The seconds is an integer between 120 and 86,400 seconds. The no isakmp policy priority lifetime command resets the security association lifetime to the default value of 86,400 seconds (one day). The syntax and an example are as follows:
Pix(config)# isakmp policy priority lifetime seconds Pix(config)# isakmp policy 100 lifetime 5000
The following example shows two defined IKE policies. The highest priority—Policy 100—would be preferred by this device.
Pix(config)# isakmp policy 100 encryption 3des Pix(config)# isakmp policy 100 hash md5 Pix(config)# isakmp policy 100 authentication rsa-sig Pix(config)# isakmp policy 100 group 2 Pix(config)# isakmp policy 100 lifetime 10000 Pix(config)# isakmp policy 200 encryption des Pix(config)# isakmp policy 200 authentication pre-share
In the previous example, the third and sixth lines wouldn’t appear in the PIX configuration because they use the default values for those options.
Step 2.3: Configure Preshared Keys
With preshared keys, the preshared keys must be configured on both the PIX Firewall and the peer. With RSA signatures, you must configure the PIX Firewall and its peer to obtain certificates from a CA.
Configuring Preshared Keys
Configure the IKE preshared key by completing the following substeps.
Step 2.3.1: Specify the ISAKMP identity for the PIX using the configuration mode isakmp identity command. When two peers use IKE to establish IPSec security associations, each peer sends its ISAKMP identity to the remote peer. The identity can be configured as the PIX hostname (default), the PIX IP address, or a define key-id. Use the no form of the command to reset the ISAKMP identity to the default value of the host name. The syntax and two examples follow.
Pix(config)# isakmp identity {address | hostname | key-id} [key-id-string]
Pix(config)# isakmp identity address
Pix(config)# isakmp identity key-id cisco123
Reliability will increase if the PIX Firewall and its peer’s identities are set using the same method to avoid an IKE negotiation failure caused by either peer not recognizing its peer’s identity. If the host name is used as the key-string in the isakmp key command, using the host name would make sense.
Step 2.3.2: (Optional.) Define a name-to-address mapping similar to the IP Host command in the router IOS commands using the name command. Use the no form of the command to remove a name-to-address mapping. The syntax and an example follow.
Pix(config)# name ip_addr name Pix(config)# name 1.1.40.110 seattle
This step isn’t necessary if host names are resolved using a DNS server.
Step 2.3.3: Use the isakmp key command to specify a preshared authentication key and associate the key with an IPSec peer address or host name. You would configure the preshared key at both peers whenever you specify preshared key in an IKE policy. Otherwise, the policy can’t be used because it won’t be submitted for matching by the IKE process. Use the no form of the command to delete a preshared authentication key and its associated IPSec peer address. The syntax and two examples follow.
Pix(config)# isakmp key key-string address peer_addr [netmask mask] [no-xauth] [no-config-mode] Pix(config)# isakmp key cisco123 address 1.1.100.40 Pix(config)# isakmp key cisco456 address 0.0.0.0 netmask 0.0.0.0
The following are some things to consider with the isakmp key command:
-
The peer-addr can be a host or a wildcard address.
-
If no netmask is defined, the default 255.255.255.255 is used. The wildcard netmask, 0.0.0.0, allows any IPSec peer with the valid preshared key to be a valid peer. Cisco strongly recommends using a unique key for each peer.
-
While it’s possible for the PIX Firewall or any IPSec peer to use the same authentication key with multiple peers, this isn’t as secure as using a unique authentication key for each pair of peers.
-
The preshared keystring must be configured identically at both peers.
-
The keystring can be any combination of alphanumeric characters up to 128 bytes.
-
You can use the peer’s host name for the preshared key. This would seem to make the most sense with remote access implementations.
-
Preshared keys are easy to configure, but not very scalable.
Step 2.3.4: (Optional.) To see the IKE entries, use the show isakmp command. The following is an example of the output after the policies created earlier:
Pix(config)# show isakmp isakmp enable outside isakmp key ******** address 1.1.100.40 netmask 255.255.255.255 isakmp key ******** address 0.0.0.0 netmask 0.0.0.0 isakmp identity address isakmp policy 100 authentication rsa-sig isakmp policy 100 encryption 3des isakmp policy 100 hash md5 isakmp policy 100 group 2 isakmp policy 100 lifetime 10000 isakmp policy 200 authentication pre-share isakmp policy 200 encryption des isakmp policy 200 hash sha isakmp policy 200 group 1 isakmp policy 200 lifetime 86400 Pix(config)#
Configuring CAs
The following steps are used to enable the PIX Firewall to interoperate with a CA and obtain PIX Firewall certificate(s).
| Note? |
The PIX Firewall clock must be set to Greenwich Mean Time (GMT), month, day, and year before configuring CA. Otherwise, the CA might reject certificates based on a bad timestamp. The PIX Firewall uses the clock to make sure a CRL isn’t expired. |
Step 2.3.1: Use the hostname command to configure the PIX Firewall host name. The syntax and examples follow.
pixfirewall(config)# hostname name pixfirewall(config)# hostname Pix Pix(config)#
Step 2.3.2: Use the domain-name command to configure the PIX Firewall domain name. The syntax and an example follow.
Pix(config)# domain-name name Pix(config)# domain-name test.com
Step 2.3.3: Use the ca generate rsa key command to configure the generation of the RSA key pair(s). The syntax and an example follow.
Pix(config)# ca generate rsa key key_modulus_size Pix(config)# ca generate rsa key 512
In the example, one general purpose RSA key pair is to be generated with a key modulus set to 512.
The following is an example of using the show ca mypubkey rsa to see the RSA key pair(s).
Pix(config)# show ca mypubkey rsa % Key pair was generated at: 15:46:58 UTC Jan 26 2003 Key name: Pix.test.com Usage: General Purpose Key Key Data: ?305c300d 06092a86 4886f70d 01010105 00034b00 30480241 00c11fac 224f11ea ?05b81343 6f14e27c 1be96be3 11a5b63b 8ca615c8 39a1844f 89cc48ec 0039423c ?1aeb56b8 c07f3da4 e496c23e d291d458 7aef9c57 cb0ff327 bd020301 0001 Pix(config)#
Step 2.3.4: Use the ca identity command to declare a CA. The syntax and an example follow.
Pix(config)# ca identity ca_nickname ca_ipaddr [:ca_script_location] [ldap_ip addr] Pix(config)# ca identity testca.test.com 1.1.100.100
In the example, 1.1.100.100 is the IP address of the CA, testca.test.com.
Step 2.3.5: Use the ca configure command to configure the parameters of communication between the PIX Firewall and the CA. Use the no form of the command to reset the communication parameters to the default value. The syntax and an example follow.
Pix(config)# ca configure ca_nickname {ca | ra} retry_period retry_count [crloptional]
Pix(config)# ca configure testca.test.com ca 1 15 crloptional
|
CA | RA |
Whether to contact the CA or the registration authority (RA) with the ca configure command. |
|
retry_period |
Number of minutes the PIX waits before resending a certificate request to the CA if it doesn’t get a response. Range 1 to 60 minutes. Default is one minute. |
|
retry_count |
How many attempts the PIX Firewall will make to resend a request if it doesn’t get a response. Range 0 to 100. Default is 0, indicating no limit. |
|
crloptional |
Allows other peers’ certificates to be accepted by the PIX even if the certificate revocation list (CRL) isn’t available. Default is without the crloptional. |
Use the show ca configure command to display the current settings stored in RAM.
Step 2.3.6: Use the ca authenticate command to allow the PIX to authenticate its CA by obtaining the CA’s self-signed certificate, which contains the CA’s public key. When using the RA mode (ca configure command) and when issuing the ca authenticate command, the RA signing and encryption certificates will be returned from the CA, as well as the CA certificate. The syntax and an example follow.
Pix(config)# ca authenticate ca_nickname [fingerprint] Pix(config)# ca authenticate testca.test.com 0123456789ABCDEF0123
The optional fingerprint (0123456789ABCDEF0123), when used, authenticates the CA’s public key within its certificate. The PIX will discard the CA certificate if this fingerprint doesn’t match the fingerprint in the CA’s certificate.
Step 2.3.7: Use the ca enroll command to request signed certificates from your CA for all PIX RSA key pairs. One command gets all pairs. Contact the CA administrator before running this command because the administrator must authenticate the PIX Firewall manually before granting its certificate(s). The syntax and an example follow.
Pix(config)# ca enroll ca_nickname challenge_password [serial] [ipaddress] Pix(config)# ca enroll testca.test.com mypassword1234567 serial ipaddress
|
challenge_password |
Required password the CA administrator uses when a user calls to ask for a certificate to be revoked. Up to 80 characters in length. |
|
serial |
Get the PIX unit’s serial number from the certificate. |
|
ipaddress |
Get the PIX unit’s IP address from the certificate. |
| Note? |
This password is most important and is required to revoke a certificate. Note this password and store it in a safe place. |
Step 2.3.8: Use the show ca certificate to verify the process was successful.
The following is sample output from the show ca certificate command including a PIX Firewall general purpose certificate and the RA and CA public-key certificates:
Pix(config)# show ca certificate Subject Name Name: Pix.test.com IP Address: 1.1.1.1 Status: Available Certificate Serial Number: 47d16514 Key Usage: General Purpose RA Signature Certificate Status: Available Certificate Serial Number: 47d165f7 Key Usage: Signature CA Certificate Status: Available Certificate Serial Number: 47d165e2 Key Usage: Not Set RA KeyEncipher Certificate Status: Available Certificate Serial Number: 47d165f6 Key Usage: Encryption
Step 2.3.9: Save the configuration:
Step 2.4: Verify IKE Configuration
To see the IKE entries, use the show isakmp command. The following is an example of the output after the policies created earlier. Notice the default parameters are listed for the items not specifically configured.
Pix(config)# show isakmp isakmp enable outside isakmp policy 100 authentication rsa-sig isakmp policy 100 encryption 3des isakmp policy 100 hash md5 isakmp policy 100 group 2 isakmp policy 100 lifetime 10000 isakmp policy 200 authentication pre-share isakmp policy 200 encryption des isakmp policy 200 hash sha isakmp policy 200 group 1 isakmp policy 200 lifetime 86400 Pix(config)#
Use the show isakmp policy command to view all existing IKE policies. The following is an example of the output after the policies created earlier. Notice the default parameters are listed at the bottom.
Pix(config)# show isakmp policy Protection suite of priority 100 ?????encryption algorithm: ?3DES - Data Encryption TripleDES (168 bit keys) ?????hash algorithm: ???????Message Digest 5 ?????authentication method: Rivest-Shamir-Adleman Signature ?????Diffie-Hellman group: ?#2 (1024 bit) ?????lifetime: ?????????????10000 seconds, no volume limit Protection suite of priority 200 ?????encryption algorithm: ?DES - Data Encryption Standard (56 bit keys) ?????hash algorithm: ???????Secure Hash Standard ?????authentication method: Pre-Shared Key ?????Diffie-Hellman group: ?#1 (768 bit) ?????lifetime: ?????????????86400 seconds, no volume limit Default protection suite ?????encryption algorithm: ?DES - Data Encryption Standard (56 bit keys) ?????hash algorithm: ???????Secure Hash Standard ?????authentication method: Rivest-Shamir-Adleman Signature ?????Diffie-Hellman group: ?#1 (768 bit) ?????lifetime: ?????????????86400 seconds, no volume limit Pix(config)#
Use the show isakmp sa command to view all current IKE security associations between the PIX Firewall and its peer. The following output is an example of the show isakmp sa command after IKE negotiations were successfully completed between the PIX Firewall and a peer.
Pix(config)# show isakmp sa ???????dst ???????????src ????????state ????pending ???created ????1.1.10.10 ?????1.1.1.14 ?????QM_IDLE ???????0 ??????????1
Task 3: Configure IPSec Parameters
The next major task is to configure the IPSec parameters you determined in Task 1. This task consists of five basic configuration steps that define IPSec SA parameters between peers and the set global IPSec values. The steps are as follows.
-
Step 3.1: Configure crypto access lists.
-
Step 3.2: Configure transform set suites.
-
Step 3.3: Configure global IPSec SA lifetimes (optional).
-
Step 3.4: Configure crypto maps.
-
Step 3.5: Apply crypto maps to the terminating/originating interface.
Bypassing Interface ACLs
The PIX security model requires that any inbound session must be explicitly permitted by an access list or conduit statement. With IPSec connections, the secondary access list filtering could be redundant. Use the sysopt connection permit-ipsec command in IPSec configurations to permit IPSec traffic to pass through the firewall without inspection by the interface access list or conduit command statements.
Without the sysopt connection permit-ipsec command, it’s necessary to explicitly configure an access-list command statement to permit IPSec traffic to traverse the PIX Firewall. Use the no form of the command to disable the option. The syntax and an example follow.
Pix(config)# sysopt connection {permit-pptp | permit-l2tp | permit-ipsec}
Pix(config)# sysopt connection permit-ipsec
Step 3.1: Configure Crypto Access Lists
The first major step in configuring PIX Firewall IPSec is to configure crypto access lists to define which IP traffic is interesting and will be protected by IPSec, and which traffic won’t be protected by IPSec. Crypto access lists perform the following functions:
-
Define the data traffic to be protected by IPSec.
-
Filter inbound traffic and discard any traffic that should have been protected by IPSec.
-
Determine whether to accept requests for IPSec SAs for the requested dataflows when processing IKE negotiations.
Define a crypto access list with the access-list global configuration command. Use the no form of the command to delete an entire access list. The syntax and an example follow.
Pix(config)# access-list acl-name {deny | permit} protocol src-addr src-netmask [operator port [port]] dest dest-netmask [operator port [port]]
Pix(config)# access-list 150 permit ip 1.1.40.0 255.255.255.0 1.1.2.0
255.255.255.0
While the access list syntax is the same as those applied to PIX Firewall interfaces, the meanings are slightly different for crypto access lists. Permit statements specify that any matching packets must be encrypted, while deny statements specify that any matching packets needn’t be encrypted.
Some additional details for access lists are as follows.
-
Any unprotected inbound traffic matching a permit statement in the crypto access list for a crypto map is dropped because it should have been encrypted.
-
Using port ranges can dramatically increase the number of IPSec tunnels the PIX Firewall can originate or terminate. A new tunnel is created for each port.
-
Creating two different crypto access lists would be necessary to define two different types of traffic that require different combinations of IPSec protection. One type could define the traffic requiring authentication and encryption, while the second type might define traffic requiring authentication only.
Keyword Any Issues
Extreme care should be used with the any keyword to define source or destination addresses. Particularly the permit any any statement, which would cause all outbound traffic to be protected and sent to the peer defined in the corresponding crypto map statement. It would also require protection for all inbound traffic and, any not protected, would be silently dropped.
Before using the any keyword in any permit statement, it’s important to preface that statement with a series of deny statements to filter out any traffic that doesn’t need to be protected.
Step 3.2: Configure Transform Set Suites
The next step in configuring PIX Firewall IPSec is to use the IPSec security policy to define a transform set. A transform set is a combination of individual IPSec transforms grouped to define a specific security policy for traffic. During IKE phase two negotiation for IPSec SA, the peers agree to use a particular transform set for protecting a particular dataflow. Transform sets combine the following IPSec factors:
-
Payload authentication: AH transform
-
Payload encryption: ESP transform
-
IPSec mode (transport or tunnel)
Transform sets equal a combination of an AH transform, an ESP transform, and the IPSec mode, Tunnel (default) or Transport mode. Transform sets are limited to up to one AH and up to two ESP transforms. IPSec peers must have at least one matching transform set configured.
If you specify an ESP protocol in a transform set, you can specify only an ESP encryption transform or both an ESP encryption transform and an ESP authentication transform. The PIX Firewall supports the following IPSec transforms.
|
ah-md5-hmac |
AH-HMAC-MD5 transform |
|
ah-sha-hmac |
AH-HMAC-SHA transform |
|
esp-des |
ESP transform using DES cipher (56 bits) |
|
esp-3des |
ESP transform using 3DES(EDE) cipher (168 bits) |
|
esp-md5-hmac |
ESP transform with HMAC-MD5 authentication used with an esp-des or esp-3des transform to provide additional integrity of ESP packet |
|
esp-sha-hmac |
ESP transform with HMAC-SHA authentication used with an esp-des or esp-3des transform to provide additional integrity of ESP packet |
AH’s lack of compatibility with NAT and PAT, as well as the fact that ESP is now available with authentication using the esp-sha-hmac and esp-md5-hmac transforms, makes AH an infrequent choice.
Use the configuration mode crypto ipsec transform-set command to define a transform set with up to three transoms. Before a transform set can be included in a crypto map entry, it must be defined using the crypto ipsec transform-set command. Use the no form of the command to delete a transform set. The syntax and an example follow.
Pix(config)# crypto ipsec transform-set trans-name [ah-md5-hmac | ?ah-sha-hmac] [esp-des | esp-null] [esp-md5-hmac|esp-sha-hmac] Pix(config)# crypto ipsec transform-set seattle esp-des esp-md5-hmac
Windows 2000 Issue
The Windows 2000 L2TP/IPSec client uses IPSec Transport mode, so Transport mode must be selected on the transform set. The default is Tunnel mode. The crypto ipsec transform-set trans -name mode transport command specifies IPSec Transport mode for a transform set.
For PIX Firewall version 6.0 and higher, L2TP is the only protocol that can use the IPSec Transport mode. All other types of packets using IPSec Transport mode will be discarded by the PIX Firewall. Use the no form of the command to reset the mode to the default value of Tunnel mode.
Pix(config)# crypto ipsec transform-set trans-name mode transport Pix(config)# crypto ipsec transform-set tacoma ah-md5-hmac esp-des esp-sha-hmac Pix(config)# crypto ipsec transform-set tacoma mode transport
The following is sample output for the show crypto ipsec transform-set command displaying the result of the previous transform definition. The syntax and an example follow:
Pix(config)# show crypto ipsec transform-set
Transform set seattle: { esp-des esp-md5-hmac ?}
??will negotiate = { Tunnel, ?},
Transform set tacoma: { ah-md5-hmac ?}
??will negotiate = { Transport, ?},
??{ esp-des esp-sha-hmac ?}
??will negotiate = { Transport, ?},
Pix(config)#
Step 3.3: Configure Global IPSec SA Lifetimes (Optional)
The IPSec SA lifetime defines how long IPSec SAs remain valid before they’re renegotiated. The configuration mode crypto ipsec security-association lifetime command defines a global lifetime value that applies to all crypto maps. This global value can be overridden within a crypto map entry. The lifetime can be defined in either seconds or kilobytes. Use the no form of the command to reset a lifetime to the default value. The syntax and two examples follow.
Pix(config)# crypto ipsec security-association lifetime {seconds seconds |
kilobytes kilobytes}
Pix(config)# crypto ipsec security-association lifetime seconds 2700
Pix(config)# crypto ipsec security-association lifetime kilobytes 2304000
|
seconds seconds |
Seconds a SA lives before expiring. Default: 28,800 (eight hours). |
|
kilobytes kilobytes |
Traffic volume (in kilobytes) that can pass between IPSec peers using a SA before it expires. Default: 4,608,000 (approximately 10 Mbps of traffic for one hour). |
The following output is an example of using the show crypto ipsec security-association lifetime command to see the previous entries.
Pix(config)# show crypto ipsec security-association lifetime Security association lifetime: 2304000 kilobytes/2700 seconds Pix(config)#
Step 3.4: Configure Crypto Maps
Crypto map statements must be configured for IPSec to set up SAs for traffic flows that must be encrypted. Crypto map statements set up SA parameters, tying together the various parts required to set up IPSec SAs, including the following:
-
The type and granularity of traffic to be protected by IPSec. Uses a crypto access list to define.
-
Where outbound IPSec-protected traffic should be sent (the remote IPSec peer).
-
The local address to use for the IPSec traffic.
-
What type of IPSec security, transform sets, should be applied to the traffic.
-
Whether SAs are established via ISAKMP or manually configured.
-
The IPSec SA lifetime.
Use the following substeps to configure a crypto map with the following forms of the crypto map command.
Step 3.4.1: Use the crypto map ipsec-manual | ipsec-isakmp command to create or modify a crypto map entry. Use the ipsec-manual option to create or modify an ipsec-manual crypto map entry. Use the ipsec-isakmp option to create or modify an ipsec-isakmp crypto map entry. A crypto map command without a keyword creates an ipsec-isakmp entry by default. Use the no crypto map command to delete a crypto map entry or set. The syntax and two examples follow.
Pix(config)# crypto map map-name seq-num [ipsec-isakmp | ipsec-manual] Pix(config)# crypto map testmap 10 ipsec-isakmp Pix(config)# crypto map testmap2 10 ipsec-manual
Step 3.4.2: Assign a crypto access list, created earlier, to the crypto map entry to be used by IPSec to determine which traffic should be protected by IPSec crypto and which traffic doesn’t need protection. Permit traffic will be protected, while deny traffic won’t be protected by IPSec.
The defined crypto access list is used to evaluate both inbound and outbound traffic. Outbound traffic is evaluated to determine if it should be protected by crypto and, if so (traffic matches a permit entry), which crypto policy to apply. Inbound traffic is evaluated to determine if it should have been protected by crypto. If the inbound traffic should have been protected, but wasn’t, it’s discarded as suspect.
The access list is also used to identify the flow for which the IPSec security associations are established. In the outbound case, the permit entry is used as the dataflow identity (in general). In the inbound case, the data flow identity specified by the peer must be “permitted” by the crypto access list.
Use the following syntax to assign a crypto access list to a crypto map. Use the no form of the command to reverse the command. The syntax and an example follow.
Pix(config)# crypto map map-name seq-num match address acl-name Pix(config)# crypto map testmap 10 match address 150
Remember, the crypto access list doesn’t determine whether to permit or deny traffic through the interface. An access list applied directly to the interface with the access- group command makes that determination.
Step 3.4.3: Use the crypto map set peer command to define the IPSec peer in a crypto map entry. The peer is the terminating interface of the IPSec peer. This command is required for all static crypto maps, except for a dynamic crypto map (with the crypto dynamic-map command). Use the no form of the command to remove an IPSec peer from a crypto map entry. The syntax and an example follow.
Pix(config)# crypto map map-name seq-num set peer {hostname | ip-address}
Pix(config)# crypto map testmap set peer 1.1.40.25
You can specify multiple peers for ipsec-isakmp crypto entries by repeating the command. The peer that packets are sent to is determined by the last peer the PIX Firewall 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.
You can only specify one peer per crypto map with ipsec-manual crypto entries. To change a peer, you must first delete the old peer, and then specify the new peer.
Step 3.4.4: IPSec peers negotiate a matching transform set during IKE phase two. Only one transform set can be defined for an ipsec-manual crypto map, but both ipsec-isakmp and dynamic crypto map entries can have up to six transform sets. When defining multiple transform sets, list them in preference (priority) starting with the highest priority. The most secure transforms should be the highest priority and, therefore, early in the list.
Use the crypto map set transform-set command to define which transform set(s) can be used with the crypto map entry. Before a transform set can be included in a crypto mapset entry, it must be defined using the crypto ipsec transform-set command. Use the no crypto map set transform-set command to remove all transform sets from a crypto map entry. The syntax and an example follow.
Pix(config)# crypto map map-name seq-num set transform-set trans-name1 [trans-name2, trans-name6] Pix(config)# crypto ipsec transform-set seattle esp-des esp-md5-hmac Pix(config)# crypto map testmap 10 set transform-set seattle
Step 3.4.5: (Optional.) Perfect forward secrecy (PFS) requires a new Diffie–Hellman exchange every time a new SA is negotiated for ipsec-isakmp crypto map entries and dynamic crypto map entries. PFS adds an additional level of security because if one key is ever compromised, only the data sent with that key will be affected. This additional security does require additional processing resources and time. PFS isn’t on by default.
Use the crypto map set pfs command to ask for PFS and the no form of the command to turn off the feature. The default (group1) is used if the set pfs statement doesn’t specify a group. The 1024-bit Diffie–Hellman group2 provides more security than group1, but it also consumes more processing time than group1. The syntax and two examples follow.
Pix(config)# crypto map map-name seq-num set pfs [group1 | group2] Pix(config)# crypto map testmap 10 set pfs Pix(config)# crypto map testmap 10 set pfs group2
Step 3.4.6: (Optional.) Use the crypto map set security-association lifetime command to override the global lifetime value for a particular crypto map entry. The global lifetime is used when negotiating IPSec security associations. While the command increases security levels, this is at the expense of additional CPU resources. This option is only available for ipsec-isakmp crypto map entries and dynamic crypto map entries. Use the no form of the command to reset a crypto map entry’s lifetime value to the global value. The syntax and an example follow.
Pix(config)# crypto map map-name seq-num set security-association lifetime
{seconds seconds | kilobytes kilobytes}
Pix(config)# crypto map testmap 10 set security-association lifetime
seconds 2700
Step 3.4.7: (Optional.) Five crypto dynamic-map commands cover many of the IPSec parameters just introduced. These commands can be used to define dynamic crypto map features. A dynamic crypto map entry is basically a crypto map entry without all the parameters configured. It acts as a policy template where the missing parameters are later dynamically configured to match a peer’s requirements as the result of an IPSec negotiation. This allows peers to exchange IPSec traffic with the PIX Firewall, even if the PIX Firewall doesn’t have a crypto map entry specifically configured to meet all the peer’s requirements.
The following is the syntax of the commands:
crypto dynamic-map dyn-map-name dyn-seq-num match address acl-name crypto dynamic-map dyn-map-name dyn-seq-num set peer {hostname | ip-address} crypto dynamic-map dyn-map-name dyn-seq-num set pfs [group1 | group2] crypto dynamic-map dyn-map-name dyn-seq-num set security-association lifetime seconds seconds | kilobytes kilobytes crypto dynamic-map dyn-map-name dyn-seq-num set transform-set trans-set-name1 [ trans-set-name9]
The following output shows an example of using each of the commands:
Pix(config)# crypto dynamic-map reachus 20 match address 150
Pix(config)# crypto dynamic-map reachus 20 set peer 1.1.70.25
Pix(config)# crypto dynamic-map reachus 20 set pfs group2
Pix(config)# crypto dynamic-map reachus 20 set security-association lifetime seconds10000
Pix(config)# crypto dynamic-map reachus 20 set transform-set tacoma
The show crypto dynamic-map command is used to display the dynamic crypto map information.
The following output shows the minimum commands required for crypto map configuration when IKE is used to establish the security associations.
Pix(config)# access-list 150 permit ip 1.1.40.0 255.255.255.0 1.1.2.0 ?255.255.255.0 Pix(config)# crypto transform-set testset ah-md5-hmac esp-sha-hmac Pix(config)# crypto map testmap 10 ipsec-isakmp Pix(config)# crypto map testmap 10 match address 150 Pix(config)# crypto map testmap 10 set transform-set testset Pix(config)# crypto map testmap 10 set peer 1.1.40.7
The following example shows the minimum required crypto map configuration when the security associations are manually established.
Pix(config)# access-list 150 permit ip 1.1.40.0 255.255.255.0 1.1.2.0 ?255.255.255.0 Pix(config)# crypto transform-set testset2 ah-md5-hmac esp-des Pix(config)# crypto map testmap2 10 ipsec-manual Pix(config)# crypto map testmap2 10 match address 150 Pix(config)# crypto map testmap2 10 set transform-set testset2 Pix(config)# crypto map testmap2 10 set peer 1.1.40.7 Pix(config)# crypto map testmap2 10 set session-key inbound ah 256 ?12093487567854903212093487568903 Pix(config)# crypto map testmap2 10 set session-key outbound ah 256 ?asdfghjklpoiuytrewqzxcvbnmqazxsw Pix(config)# crypto map testmap2 10 set session-key inbound esp 256 ?cipher 8765432167890543 Pix(config)# crypto map testmap2 10 set session-key outbound esp 256 ?cipher plokmnjiuhbvgytf Pix(config)#
Step 3.5: Apply Crypto Maps to the Terminating/Originating Interface
The next step in configuring IPSec is to apply the crypto map set to an interface before that interface can provide IPSec services. Only one crypto map set can be assigned to an interface. If multiple crypto map entries have the same map name, but have a different seq-num, they’re considered as part of the same crypto map set and will all be applied to the interface. The crypto map entries with the lowest seq-num are considered the highest priority and will be processed first. A single crypto map set can contain a combination of ipsec-isakmp and ipsec-manual crypto map entries.
While the current PIX software, since 5.1, supports IPSec termination on any active interface, this doesn’t mean you terminate traffic coming from the outside on the inside interface. VP traffic terminated on any interface originated on the networks attached to that interface. Traffic terminated on the inside interface originated from the inside network— the same with the outside interface and any DMZs.
Use the crypto map interface command to assign a crypto map set to any active PIX Firewall interface. Use the no form of the command to remove the crypto map set from an interface. The syntax and an example follow.
Pix(config)# crypto map map-name interface int-name Pix(config)# crypto map testmap interface outside
Task 4: Test and Verify VPN Configuration
The final task is to verify the IPSec configuration and confirm it’s working properly. Several commands were introduced throughout the section, but a summary of those commands that would be most useful includes the following.
The show crypto map command is used to display the crypto map configuration. The show crypto map [interface interface | tag map-name] command can be used to limit the display to a single interface or a crypto map name.
Pix(config)# show crypto map
Crypto Map: "testmap" interfaces: { outside }
Crypto Map "testmap" 10 ipsec-isakmp
???????access-list 150; 1 elements
???????access-list 150 permit ip 1.1.40.0 255.255.255.0 1.1.2.0 255.255.255.0 (
hitcnt=0)
???????Current peer: 0.0.0.0
???????Security association lifetime: 2304000 kilobytes/2700 seconds
???????PFS (Y/N): Y
???????DH group: ?group2
???????Transform sets={ seattle, }
Pix(config)#
To view the configured transform sets, use the show crypto ipsec transform-set command.
Pix(config)# show crypto ipsec transform-set
Transform set seattle: { esp-des esp-md5-hmac ?}
??will negotiate = { Tunnel, ?},
Transform set tacoma: { ah-md5-hmac ?}
??will negotiate = { Tunnel, ?},
??{ esp-des esp-sha-hmac ?}
??will negotiate = { Tunnel, ?},
Pix(config)#
The show crypto ipsec security-association lifetime command displays the security-association lifetime value configured for a particular crypto map entry.
Pix(config)# show crypto ipsec security-association lifetime Security association lifetime: 2304000 kilobytes/2700 seconds Pix(config)#
The show access-list command displays all current ACLs, as well as an activity counter (hitcnt=#), which indicates the number of times the statement was used since the last time a clear access-list command was issued or the device was rebooted. If the acl-id is added to the command, the output is limited to that access list.
Pix(config)# show access-list access-list 150; 1 elements access-list 150 permit ip 1.1.40.0 255.255.255.0 1.1.2.0 255.255.255.0 (hitcnt=7) Pix(config)#
The show crypto ipsec sa command displays the settings used by current security associations. If no keyword is used, all security associations are displayed. First, they’re sorted by interface, and then they’re sorted by traffic flow (for example, source/destination address, mask, protocol, port). Within a flow, the security associations are listed by protocol (ESP/AH) and direction (inbound/outbound).
Pix(config)# show crypto ipsec sa interface: outside ???Crypto map tag: testmap, local addr. 1.1.1.1 Pix(config)#
The debug crypto isakmp and debug crypto ipsec commands can be used to monitor the related activity in real time.
