|
|
Deploying IPsec VPNs: Fundamental ConsiderationsWhen deploying an IPsec VPN, there are a number of fundamental considerations, including the following:
These considerations are discussed in the remainder this chapter. The sample topology shown in Figure 6-31 is used to illustrate the various concepts discussed. Figure 6-31. Sample IPsec VPN Topology
Selecting and Configuring IKE Policies for Automated SA and Key ManagementWhen deploying IPsec VPNs with IKE, it is important to select the appropriate IKE parameters such as method of authentication and encryption algorithm to ensure that the VPN is both secure and scalable. IKE parameters are collectively known as a protection suite. As previously mentioned, the purpose of IKE is to allow IPsec peers (IPsec VPN gateways) to dynamically authenticate each other, negotiate cryptographic parameters, and agree on session keys. Selecting the Appropriate Method of IKE AuthenticationCisco routers can support three methods of authentication for IKE: The sections that follow cover these methods of authentication in greater detail. IKE Preshared Key AuthenticationYou can configure IKE preshared key authentication on all Cisco devices that support IPsec. Example 6-1 shows configuration of an IKE (ISAKMP) preshared key on a Cisco IOS router using the crypto isakmp key keystring address peer-address [mask] command. Example 6-1. Configuring Preshared Key Authentication
In Example 6-1, the preshared key is 1tdsKre*7: 'W12345sQw'#%5, and the peer's IP address is 192.168.2.2. The preshared key is an alphanumeric string and must be configured identically on peer IPsec VPN gateways. If the preshared key is not configured identically on peer IPsec VPN gateways, IKE authentication will fail, and the IPsec tunnel(s) will not come up. The address parameter is used to specify the identity of the remote IPsec peer in the form of an IP address. Normally, you specify one preshared key per remote IPsec VPN gateway. Having one preshared per remote gateway is best from a security perspective, but with a large number of remote gateways administration can become burdensome. It is possible to specify a wildcard address (0.0.0.0) rather than a specific IP address. If you specify a wildcard address, a remote host with any IP address can establish an IPsec tunnel using the configured preshared key. Example 6-2 illustrates configuration of a wildcard preshared key. Example 6-2. Configuring a Wildcard Preshared Key
Although wildcard preshared keys can occasionally be useful, you should be aware of the security risks. A regular preshared key can only be used by the IPsec VPN gateway specified (for example, 192.168.2.2 in Example 6-2). But when you configure a wildcard preshared key, an attacker with any IP address can connect to the IPsec VPN gateway if he/she is able to find out the preshared key (something that is quite possible if you choose a weak preshared key). It is worth taking a closer look at the preshared keystring itself. Notice that in Example 6-1 the keystring is pretty random (1tdsKre*7: 'W12345sQw'#%5). The (relative) randomness of the keystring is deliberateif the keystring is easily guessable, it is weak and vulnerable to attack. So, make sure that your preshared keys are long, random strings of lower- and uppercase characters, numbers, and punctuation. It is possible to launch brute-force attacks against weak preshared keys, especially if you use aggressive mode for phase 1 IKE negotiation. If you use main mode for IKE phase 1 negotiation, it is more difficult but still possible for an attacker to recover a weak preshared key. Do not be lulled by the strength of cryptographic algorithms such as SHA-1, 3DES, and AES, thinking that it does not matter whether preshared keys are (relatively) random. Preshared keys can be the weak link that undermines IPsec as a whole. Note The vulnerability of weak preshared keys has been extensively documented. For more information, refer to the following sites: http://www.ernw.de/download/pskattack.pdf http://www.cisco.com/warp/public/707/cisco-sn-20030422-ike.html Now that you know how vulnerable weak preshared keys can be to attack, it is useful to list some recommendations for using preshared key authentication:
Example 6-4 shows the encryption of preshared keys in a configuration file. Example 6-4. Encrypting Preshared Keys in a Configuration File
Highlighted line 1 shows that the preshared key is cisco. Note that this is a weak preshared key and is used for illustrative purposes only. In highlighted lines 2, a master key that will be used to encrypt all preshared keys within the configuration file is configured using the key config-key password-encrypt [master-key] command. In this example, the master key is psk123encrypt. The master key is not stored within the configuration file and cannot be obtained by users that connect to the router. In highlighted line 3, the password encryption aes command is used to enable encryption of preshared keys within the configuration file using the AES. Finally, in highlighted line 4, you can see the preshared key in its encrypted form within the configuration file. IKE Encrypted Nonce AuthenticationThe second option for IKE authentication is encrypted nonce authentication. Note Encrypted nonce authentication can be configured only on Cisco routers, and not on PIX Firewalls, ASA 5500s, or VPN 3000 concentrators. In you want to use encrypted nonce authentication, you must complete the following tasks on each IPsec VPN gateway:
You can configure an IPsec VPN gateway's host name and IP domain name using the hostname hostname and ip domain-name domain-name commands, as demonstrated in Example 6-5. Example 6-5. Configuring the Host Name and IP Domain Name
In Example 6-5, an IPsec VPN gateway's host name and domain name are configured as London and mjlnet.com, respectively. The host name and domain name are concatenated into the fully qualified domain name (FQDN) London.mjlnet.com. After you have configured the host name and domain name, the next step is to generate RSA keys on the IPsec VPN gateway using the crypto key generate rsa [usage-keys | general-keys] [key-pair-label] command, as demonstrated in Example 6-6. Example 6-6. Generating RSA Keys on an IPsec VPN Gateway
In highlighted line 1, the crypto key generate rsa command is used to generate RSA general usage keys (keys that can be used for either signing or encryption). If you specify the usage-keys keyword, separate keys are generated for encryption and signing. The message shown in highlighted line 2 indicates that the name assigned to the key pair (public and private keys) will be London.mjlnet.com (the FQDN). The default name assigned to the key pair is the FQDN, but if you do want to assign a different name to a key pair, you can specify it using the key-pair-label parameter when you use the crypto key generate rsa command. Highlighted line 3 specifies a key size (modulus) of 1024 bits. You can specify a key modulus of 360 to 2048 bits. The shorter the key modulus, the less secure the key pair is, so recommended practice is that you use a minimum key modulus of 1024 bits. After you have generated RSA keys on your IPsec VPN gateways, the next step is to exchange the peer gateways' public keys and paste them into the configuration of the IPsec VPN gateways. For example, after you have generated RSA keys on the London and Berlin gateways (see Figure 6-31), you should paste the public key(s) from the Berlin gateway into the configuration of the London gateway and the public key(s) of the London gateway into the configuration of the Berlin gateway. In Figures 6-32, 6-33, and 6-34, the public key of the Berlin gateway is displayed, and then it is copied and pasted into the configuration of the London gateway. Figure 6-32. Displaying and Copying the Public Key of the Berlin IPsec VPN Gateway
Figure 6-33. Preparing to Paste Berlin's Public Key into the Configuration of the London IPsec VPN Gateway
Figure 6-34. Berlin's Public Key Is Pasted to the London IPsec VPN Gateway
In Figure 6-32, the show crypto key mypubkey rsa command is used to display the public key of the Berlin gateway. This public key is copied. In Figure 6-33, the crypto key pubkey-chain rsa command is used on the London IPsec VPN gateway to enter the public key configuration mode. The named-key key-name command is then used to specify the name (FQDN) of the key to be manually configured (in this example, Berlin.mjlnet.com). Finally, the key-string command is used to enter the mode in which the public key from the peer gateway (Berlin in this example) can be pasted into the configuration. As shown in Figure 6-34, after the key-string command has been entered, the public key of the remote gateway is pasted, and the quit command is used to exit public key configuration mode. You might be thinking to yourself that IKE encrypted nonce authentication looks like a lot of hard work, especially if you have a large number of gateways in your VPN. Well, you are right; it is a lot of hard work (imagine copying and pasting all those public keys), and that is the reason that it is not a common method of IKE authentication. So, when might you use encrypted nonce authentication? Well, you might possibly use it if you are concerned about weak preshared keys but you do not want to go to the trouble of deploying the PKI necessary to enable digital signature authentication. In summary, IKE encrypted nonce authentication is more secure than preshared key authentication, but it is a lot of trouble to set it up for a large number of IPsec peers. Most people opt for preshared key authentication (while avoiding weak preshared keys) or, much better, use digital signature authentication. IKE Digital Signature AuthenticationThe third and final method of IKE authentication is RSA digital signature authentication using digital certificates. You must complete a number of steps on each IPsec VPN gateway if you want to use digital signature authentication in your IPsec VPN:
These steps are examined in the sections that follow. Step 1: Set the Time on the IPsec VPN GatewaysEnsuring that the time is correctly set on IPsec VPN gateways is important when using digital signature authentication. Certificates are valid for a certain time period only, and if the time is not set correctly, IKE authentication may fail, and gateways may not even be able to obtain a certificate from a CA in the first place. So, now that you know how important time is for digital signature authentication, what are the options for ensuring accurate time on the gateways? There are two options:
These methods of ensuring accurate time are discussed in the following two sections. Manually Setting the Time on Each IPsec VPN Gateway To ensure accurate time on IPsec VPN gateways by manually setting them, use the clock set hh:mm:ss day month year command to manually set the clock, as demonstrated in Example 6-7. Example 6-7. Manually Setting the System Clock
Also, be sure to set the time zone using the clock timezone zone hours-offset [minutes-offset] command, as demonstrated in Example 6-8. Example 6-8. Setting the Time Zone
In Example 6-8, the time zone is set to be GMT (Greenwich mean time), with an offset of 0 hours from universal time coordinated (UTC). Disadvantages of manually setting time of the IPsec VPN gateways are that it is easy to make a simple error and if the systems in question do not have hardware clocks, the time will reset in the event of a reboot. Setting the Time on IPsec VPN Gateways Using NTP Another option for ensuring accurate time on the gateways in an IPsec VPN is to use NTP. The advantages of NTP are that you can be sure that all the gateways in the VPN will have accurate time (assuming that the NTP server[s] has accurate time), and that even if a gateway is rebooted it will resynchronize its time with an NTP server. The disadvantage of NTP is that an NTP server (or preferably servers) is required. Use the ntp server ip-address command to allow a gateway to synchronize its time to an NTP server, as demonstrated in Example 6-9. Example 6-9. Specifying an NTP Server Using the ntp server Command
In Example 6-9, a gateway is configured to synchronize its time to NTP server 10.10.10.99. One important consideration when using NTP is to ensure that IPsec VPN gateways synchronize their clocks with a trusted time source. It is possible for an attacker to carry out a denial-of-service attack by getting gateways to synchronize their time with a bogus time source. In this case, IKE authentication can fail if the bogus time is outside the validity period of the gateways' certificates. In addition, gateways with revoked certificates might be able continue to participate in the VPN. To ensure that gateways synchronize their clocks with a trusted time source, you can use NTP authentication, as demonstrated in Example 6-10. Example 6-10. Configuring NTP Authentication
The ntp authenticate command in Example 6-10 enables NTP authentication. The ntp authentication-key key-number md5 key-string command specifies MD5 NTP authentication with, in this example, the key string mjlnet. Note that mjlnet is not a secure choice of authentication key and is used here for illustrative purposes only. In live deployments, you should choose a random string of up to eight characters. After the authentication key has been configured, the ntp trusted-key key-number command specifies the trusted NTP key. The key number must match with that specified using the ntp authentication-key command. The ntp server ip-address key key-value command then configures the IP address of an NTP server, and specifies that the gateway will synchronize its time to that server only if the server's NTP packets can be authenticated with the previously specified trusted key (mjlnet in this example). Note If you decide to use NTP in your IPsec VPN, it is important that it be deployed in a scalable, highly available, and secure manner. A good starting point for obtaining more information concerning NTP deployment is the following white paper: http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a0080117070.shtml Step 2: Configure the IPsec VPN Gateways' Host Names and IP Domain NamesHaving set the time on the IPsec VPN gateways, the next step is to configure their IP domain names, as well host names if they have not already been configured. Example 6-11 demonstrates configuration of the IP domain name. Example 6-11. Configuring an IP Domain Name
The IP domain name of IPsec VPN gateway London is configured in Example 6-11 using the ip domain-name name command. If you have not already configured a host name on your IPsec VPN gateways, now is the time to do it using the hostname name global configuration mode command. The IPsec VPN gateways' host name and IP domain name are concatenated to produce an FQDN. Step 3: Generate RSA Keys on the IPsec VPN GatewaysNext are the IPsec VPN gateways' RSA keys. Use the crypto key generate rsa command to generate RSA keys, as demonstrated in Example 6-12. Example 6-12. Generating RSA Keys on the IPsec VPN Gateways
Notice that the name associated with the RSA key pair generated using the crypto key generate command is, by default, the FQDN of the gateway. Also, notice that a key length (modulus) of 1024 bits is specified. The minimum recommended length for RSA keys is 1024 bits. You can verify the RSA keys using the show crypto key mypubkey rsa command, as demonstrated in Example 6-13. Example 6-13. Verifying RSA Keys
Highlighted line 1 shows the RSA public key name London.mjlnet.com. Highlighted line 2 shows that the key is for general purposes (encryption and signing). The key itself is then shown in highlighted lines 3 to 7. Step 4: Declare the CAYou are almost ready to obtain the IPsec VPN gateway's certificate from the CA, but there are one or two remaining steps before you can do thatthe first of which is to declare the CA. Declaring the CA involves a number of things, including specifying a name for the CA, specifying the mode to be used for certificate enrollment, and configuring the URL to use when enrolling with the CA. Before declaring the CA, make sure that the CA's name is mapped locally on the gateway using the ip host name ip-address command or resolvable via DNS. Example 6-14 declares CA mjlnetcertsrv. Example 6-14. Declaring the CA
In highlighted line 1, the crypto pki trustpoint name command configures a locally significant name for a CA and enters ca-trustpoint configuration mode. Note The crypto pki trustpoint command replaces the crypto ca trustpoint, crypto ca identity, and crypto ca trusted-root commands. The pki keyword also replaces the ca keyword in a number of commands in more recent versions of Cisco IOS Software. The enrollment mode ra command shown in highlighted line 2 configures the gateway to enroll with the CA using the registration authority (RA) enrollment mode. Check with your CA administrator about the enrollment mode that you should configure. Next is the enrollment url url command (highlighted line 3). This command configures the URL to be used for Simple Certificate Enrollment Protocol (SCEP) enrollment with the CA. SCEP is a protocol that supports operations such as certificate enrollment, revocation, certificate access, and CRL access. Verify the correct enrollment URL with your CA administrator. Note It is also possible to enroll with a CA either manually or using TFTP if your CA does not support SCEP. Check Cisco.com for more information. In highlighted line 4, the revocation-check method1 [method2[method3]] command specifies how the gateway should check whether peer IPsec VPN gateways' certificates have been revoked. You can specify up to three methods for the gateway to use for certificate revocation checking. If more than one method is specified, each method is tried in turn. In Example 6-14, the none keyword is specified, so the local gateway will check a CRL if one is cached in memory, but will not download a CRL from a CRL Distribution Point (CDP). The revocation-check none command replaces the crl optional command. Other keywords (methods) that you can specify with the revocation-check command are ocsp and crl. If you specify the ocsp keyword, OCSP is used to check certificate revocation status, via the OSCP responder (server) specified in the Authority Information Access (AIA) extension of a certificate (it is also possible to specify the OCSP responder manually, and override that contained in the AIA, by using the ocsp url url command in the trustpoint configuration mode). If you specify the crl keyword, the gateway will attempt to download a CRL from the CDP specified in a certificate. If you specify either the ocsp or crl keyword alone (for example, revocation-check oscp), the local gateway attempts to verify certificate status by using OCSP or by downloading a CRL as appropriate; if it is unable to contact the OCSP responder or download the CRL, however, the revocation check will not succeed, and IKE authentication will fail. A best-effort certificate revocation check can be configured by specifying the none keyword after the crl or ocsp keywords. So, for example, if you specify the revocation-check crl none command, the local gateway will attempt to download a CRL and verify the certificate's status; if it is unable to download the CRL, however, it will accept the certificate, and IKE authentication will succeed. The revocation-check crl none command replaces the crl best-effort command. Note If you specify either the none keyword alone or use best-effort certificate revocation checking (as previously discussed), it is possible for IKE authentication to succeed even if a certificate has been revoked. On the other hand, if you specify either the ocsp or crl keyword alone, it is possible for an attacker to conduct a denial-of-service attack on your IPsec VPN by targeting the OSCP responder(s) or CDP(s) and making them unavailable to the IPsec VPN gateways. In this case, if the OSCP responder or CDP is unavailable, IKE authentication will fail throughout the IPsec VPN. So, be sure you carefully weigh the options when configuring the revocation-check command. Step 5: Authenticate the CAThe penultimate step before you can enroll your IPsec VPN gateways is to authenticate the CA by obtaining its certificate, as illustrated in Figure 6-35. Figure 6-35. Authenticating the CA
Use the crypto pki authenticate name command to authenticate the CA, as demonstrated in Example 6-15, where the name parameter is that specified when declaring the CA (see Example 6-14). Example 6-15. Authenticating the CA
In Example 6-15, the CA's certificate is downloaded from the CA. At this point, you can choose to either accept or reject the CA's certificate. If the fingerprint displayed (highlighted in Example 6-15) matches the fingerprint visible to the CA administrator, you should accept the certificate. After the CA's certificate has been downloaded, you can verify the CA's certificate using the show crypto pki certificate command, as demonstrated in Example 6-16. Example 6-16. Verifying the CA's Certificate
For more information about the fields in the certificate shown in Example 6-16, see the section titled "The X.509 Certificate" in Chapter 7. Note You can also manually add (or delete) a CA's certificate in hexadecimal format using the certificate ca certificate-serial-number command within the certificate chain configuration mode. You can enter the certificate chain configuration mode using the crypto pki certificate chain name command from global configuration mode. Step 6: Enroll the IPsec VPN Gateways with the CAThe final step is to enroll the IPsec VPN gateway with the CA. During enrollment, the gateway obtains a signed certificate from the CA for each RSA key pair that you generated, as illustrated in Figure 6-36. Figure 6-36. Enrolling with the CA and Obtaining a Certificate
You can use the crypto pki enroll name command to enroll with the CA, as demonstrated in Example 6-17. The name should be the same as you specified using the crypto pki trustpoint command (see Example 6-14). Example 6-17. Enrolling with the CA
As you can see in Example 6-17, when you issue the crypto pki enroll command, you are asked to enter a password (highlighted lines 1 and 2) and then asked whether you want to include the router serial number (highlighted line 4) and IP address (highlighted line 5) in the certificate. The CA administrator may ask you to supply the challenge password in the event that you need to revoke the certificate, so make sure you note this. The serial number referred to in highlighted line 4 is not the certificate serial number (see the section "The X.509 Certificate" in Chapter 7 for more on this), but instead the gateway's internal board serial number. If you want to include an IP address in the certificate (see highlighted line 5), make sure it is the IP address of the outside interface to which the crypto map is applied, or if the crypto map is applied to multiple interfaces, the IP address specified with the crypto map local-address command. Be careful if you do decide to include an IP address in the certificate because if you do change the IP address on the outside interface (or the IP address referred to with the crypto map local-address command), IKE authentication will fail for the IPsec VPN gateway in question. In this case, you need to re-enroll the gateway with the CA, and obtain a new certificate, or change the IP address on the outside interface (or the IP address referred to with the crypto map local-address command) back to its original form. Notice the subject name shown in highlighted line 3the gateway's FQDN is, by default, included as the subject name in the gateway's certificate. The certificate is requested from the CA in highlighted line 6, and then in highlighted line 7 you can see that the certificate request is pending. The CA administrator then approves the certificate, and in highlighted line 8 the gateway receives its certificate. You can verify the certificate using the show crypto pki certificate command, as demonstrated in Example 6-18 (only the relevant output is shown). Example 6-18. Verifying the IPsec VPN Gateway's Certificate
The status of the IPsec VPN gateway's certificate is listed as Available, which indicates that the (signed) certificate has been received from the CA. For more information on the various fields in the certificate, see the section "The X.509 Certificate" in Chapter 7. Phew! All done. But, just in case you are not satisfied with the contents of your certificate, and if you prefer not to go through the dialog shown Example 6-17 (entering a password, specifying a serial number, and so on), it is possible to configure this information in advance within the crypto ca-trustpoint mode, as shown in Example 6-19. Example 6-19. Specifying Answers to the Certificate Enrollment Dialog, as Well as Certificate Fields
The usage method1 [method2 [method3]] command in highlighted line 1 specifies the usage of the certificate (in this case, IKE). In highlighted line 2, the subject-name command specifies the X.500 Distinguished Name (DN) to be used in the Subject Name field of the certificate. In this example, the country (C) is GB, the Organization (O) is MJL Network Solutions, and the organizational unit (OU) is Engineering. Highlighted line 3 specifies the IP address 192.168.1.1 using the ip-address address command. This IP address is included in the Subject Name field of the certificate. Make sure that you follow the guidelines discussed earlier in this section if you do decide to include an IP address in the certificate. Next is the serial-number command (see highlighted line 4). This command specifies that the internal board serial number should be included in the certificate. Again, the serial number is included in the Subject Name field of the certificate. If you do not want to include the gateway's serial number in the certificate, you can specify this using the serial-number none command. The challenge password is specified in highlighted line 5. This password must be supplied to the CA administrator if you need to revoke the certificate at a later date. The password specified in this example (cisco) is not secure and is used for illustrative purposes only. Caution Make sure that you save your configuration using the copy running-config startup-config command after you have generated RSA keys, authenticated the CA, and enrolled with the CA. If you do not save your configuration, information will be lost, and you will have to repeat these processes. Automating Enrollment with the CANow that you know how to enroll with the CA manually, it is useful to take a look at how this process can be automated. The auto-enrollment feature enables you to preconfigure your IPsec VPN gateway with enrollment parameters, and it will then automatically enroll with the CA. If you are configuring a large number of IPsec VPN gateways, this can really be a time saver. Example 6-20 shows the configuration necessary to enable auto-enrollment. Example 6-20. Configuring an IPsec VPN Gateway for Auto-Enrollment with the CA
Almost all of the commands shown in Example 6-20 should already be familiar, but there are one or two new commands. In highlighted line 2, you can see the auto-enroll [percent] [regenerate] command. This command configures the gateway to automatically generate RSA keys and enroll with the CA on reboot using the parameters specified. The optional rsakeypair key-label [key-size [encryption-key-size]] command (highlighted line 1) specifies which key pair you want to associate with the certificate as well as (optionally) the key size. The rsakeypair command is important because, by default, the auto-enroll command generates 512-bit RSA keys prior to enrolling with the CA. By configuring the rsakeypair command, you can specify the RSA key size (the minimum recommended is 1024 bits). There is one process that must be completed manually on the gateway before auto-enrollment can beginyou must manually authenticate the CA (as discussed in the section "Step 5: Authenticate the CA"). If you forget to authenticate the CA, the message shown in Example 6-21 displays. Example 6-21. Message Displayed If You Forget to Authenticate the CA
Automating Re-Enrollment with the CAOkay, your IPsec VPN gateways now have their certificates, and you can relax, right? Well, you can for a whilespecifically until your gateways' certificates expire. If you have manually enrolled the gateways with the CA, when the certificates expire you have to go through the entire enrollment process again on each and every gateway. Luckily (or maybe not so luckily), the auto-enroll [percentage] [regenerate] command allows your gateways to re-enroll with the CA automatically when the original certificate expires, saving you a lot of time and trouble manually re-enrolling gateways with the CA. If you specify the percentage parameter with the auto-enroll command, you can control the point at which the gateway re-enrolls with the CA. For example, if you specify 90 percent, the gateway will re-enroll with the CA when the current certificate reaches the point at which 90 percent of its validity has expired. By specifying a re-enrollment percentage, you can help to ensure that certificate enrollment is seamless, and that the gateway is not left with an old and invalid certificate that would cause IKE authentication failure. Furthermore, you can specify the regenerate keyword with the auto-enroll command if you want the gateway to generate a new RSA key pair when it re-enrolls with the CA. This can be useful because some CAs require a new key pair for re-enrollment. Example 6-22 shows the configuration of the auto-enroll command with the percentage parameter and regenerate keyword. Example 6-22. Specifying the percentage Parameter and regenerate Keyword with the auto-enroll Command
In Example 6-22, the auto-enroll command specifies a re-enrollment percentage of 90 percent. When the existing certificate reaches 90 percent of its validity period, the gateway will attempt to re-enroll with the CA. Because the regenerate keyword is also specified with the auto-enroll command in Example 6-22, the gateway will generate a new RSA key pair every time it re-enrolls with the CA. Selecting Cryptographic Parameters for IKE PoliciesAfter you have configured the IKE authentication method, the next step is to configure IKE policies. IKE policies are made up of cryptographic parameters, and are configured using the crypto isakmp policy priority command. You can configure multiple IKE policies each with a different priority (from 1 to 10000). Somewhat confusingly, lower numbered policies have a higher priority, with IKE policy 1 having the highest priority of all. A default IKE policy is automatically created with priority 65535. This policy includes all of the default IKE policy parameters discussed in this section. During IKE phase 1, IPsec peers negotiate IKE policies, starting with the highest-priority (lowest-numbered) policy, until either the peers find a matching policy and IKE negotiation succeeds or they do not find a match and IKE negotiation fails. An IKE policy (ISAKMP policy) is made up of the following elements: Configuring an Encryption Algorithm for an IKE PolicyYou can specify three encryption algorithms in an IKE policy:
Use the encryption {des | 3des | aes | aes 192 | aes 256} ISAKMP configuration mode command to configure an encryption algorithm, as demonstrated in Example 6-23. The default encryption algorithm is DES. Example 6-23. Configuration of an IKE Protection Suite
Example 6-23 specifies 3DES as the encryption algorithm within IKE policy 10. Table 6-1 shows the encryption command options.
Configuring a Diffie-Hellman Group for an IKE PolicyThe next step is to configure the Diffie-Hellman group. You can configure one of three Diffie-Hellman groups within IKE policies:
Diffie-Hellman group 5 is the most secure of the three groups but causes the most processing overhead. Diffie-Hellman group 1, on the other hand, is the least secure but causes the least overhead. Use the group {1 | 2 | 5} command to configure the Diffie-Hellman group within an IKE policy, as demonstrated in Example 6-24. Example 6-24. Configuring the Diffie-Hellman Group
In Example 6-24, a 1024-bit Diffie-Hellman group is configured for IKE policy 10. Table 6-2 summarizes group command options.
Configuring a Hash Algorithm for an IKE PolicyNext is the hash algorithm. This is used to authenticate IKE messages sent between IPsec peers. Again, there is a choice of algorithms:
For more information regarding hash algorithms, see the section "Configuring IPsec Transform Sets" later in this chapter. Specify the hash algorithm to be used with an IKE policy using the hash {sha | md5} command, as demonstrated in Example 6-25. The default hash algorithm is SHA-1. Example 6-25. Configuring the Hash Algorithm Group
The hash command is used in Example 6-25 to specify MD5 as the hash algorithm to be used within IKE policy 10. Table 6-3 shows hash command options.
Configuring an Authentication Method for an IKE PolicyYou must also specify the method of peer authentication within the IKE policy. The method of authentication can be, as previously described, the following:
Use the authentication {rsa-sig | rsa-encr | pre-share} command to configure the method of authentication to be used by an IKE policy, as demonstrated in Example 6-26. Example 6-26. Configuring the Method of Authentication
In Example 6-26, the authentication command specifies preshared key authentication. Table 6-4 shows the authentication command options.
Configuring an IKE SA Lifetime for an IKE PolicyThe final parameter that you can configure with an IKE policy is the IKE SA lifetime. When this lifetime expires, the IPsec peers renegotiate IKE phase 1. As shown in Example 6-27, use the lifetime seconds command to configure the IKE SA lifetime. The lifetime can range from 60 seconds to 86400 seconds, with the default lifetime being 86400 seconds (24 hours). Example 6-27. Configuring the Method of Authentication
Many people choose to leave the IKE SA lifetime at the default value of 86400. It is worth noting, however, that the longer the lifetime, the less secure the SA is. The SA is less secure with a longer lifetime because with a longer lifetime an attacker has more time to collect encrypted traffic and subject it to cryptanalysis (attempt to recover the plaintext). However, a shorter IKE lifetime causes IPsec peers to have to renegotiate IKE more often. So, in a particularly sensitive environment, you may choose to configure a shorter IKE SA lifetime. Caution Make sure that you configure IPsec peers with identical IKE SA lifetimes. If you do not, IKE negotiation may fail. Table 6-5 shows the lifetime command options.
Sample IKE PolicyBefore finishing this section, it is worth taking a look at a complete sample IKE policy, as shown in Example 6-28. Example 6-28. A Complete Sample IKE Policy
The sample IKE policy in Example 6-28 specifies 3DES as the encryption algorithm, SHA-1 as the hash algorithm (the default), Diffie-Hellman group 2, digital signature authentication (the default), and an IKE SA lifetime of 43200 seconds (12 hours). Note that default parameters are not shown in Example 6-28. It is generally a good idea to configure identical IKE policies for all peers in an IPsec VPN, but sometimes (particularly when configuring an extranet) it is possible that you might require one IKE policy for most peers and another policy for one or two other peers. If you do require multiple IKE policies, you can simply configure these with different priority numbers, as shown in Example 6-29. Example 6-29. Multiple IKE Policies
In Example 6-29, IKE policy 10 specifies RSA digital signature authentication (the default), 3DES encryption, the SHA-1 hash algorithm (the default), and Diffie-Hellman group 5. IKE policy 20 specifies preshared key authentication, DES encryption (the default), the MD5 hash algorithm, and Diffie-Hellman group 1 (the default). IKE policy 20 is relatively insecure because it utilizes DES. Selecting and Configuring IPsec TransformsAfter you have configured the IKE policy or policies, the next step is to specify cryptographic parameters for the IPsec transform set(s). The cryptographic parameters specified in an IPsec transform set are used as the parameters for the IPsec SAs negotiated with the remote IPsec peer during IKE phase 2. The parameters that you can specify in an IPsec transform set are as follows:
Some common considerations when selecting parameters for IPsec transform sets are as follows:
Ideally, the final two considerations are informed by the first three considerations. However, your IPsec VPN might need to be constructed using existing hardware, and available versions of Cisco IOS Software might be limited by U.S. government export controls. Selecting Security Protocols in an IPsec Transform SetYou can specify two security protocols in the IPsec transform set: As previously described, AH provides message authentication, whereas ESP can provide message authentication and/or encryption. Selecting Hash Algorithms in an IPsec Transform SetAs with IKE policies, there are two hash algorithms available with IPsec transform sets:
The MD5 algorithm generates a 128-bit hash, and the SHA-1 algorithm generates a 160-bit hash. As previously mentioned, regular MD5 and SHA-1 have been shown to be (theoretically) vulnerable to attack. Note For more information on possible attacks on regular MD5 and SHA-1, refer to the following links: ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html As previously discussed, HMAC variants of MD5 and SHA-1 differ from regular MD5 and SHA-1 in that a secret key is used as an additional input of the MD5 hash function. HMAC also adds cryptographic strength to the MD5 and SHA-1 hash function. HMAC-MD5 and HMAC-SHA-1 do not, however, significantly degrade the performance of the regular MD5 and SHA-1. It is important to note that the HMAC variants of MD5 and SHA-1 (HMAC-MD5 and HMAC-SHA-1) have not to date been shown to be vulnerable to attack. In IPsec, the 128-bit and 160-bit hashes produced by HMAC-MAC and HMAC-SHA-1 are truncated to a 96-bit length. So, in summary
Selecting Encryption Algorithms for Use with ESPYou can specify a number of encryption algorithms for use with ESP:
DES (including 3DES) and AES are block ciphers, and SEAL is a stream cipher. Block ciphers operate on blocks of plaintext (original unencrypted data) bits at one time, and stream ciphers (usually) operate on plaintext a single bit at a time. The DES, 3DES, AES, and SEAL algorithms have the following key sizes:
The most important considerations when deciding which encryption algorithm to use is the security of the encryption algorithm. The security of 56-bit DES has been questioned since its publication by the U.S. National Institute of Standards and Technology (NIST, formerly called the National Bureau of Standards [NBS]). In 1999, 56-bit DES was publicly cracked in 22 hours and 15 minutes during RSA Data Security's DES Challenge III. 56-bit DES is not considered secure. Note For more information on cracking DES, see the following URL: With a 168-bit key length, 3DES is much more secure than 56-bit DES. Standard 3DES uses two keys and involves the encryption of the plaintext with the first key, the decryption with the second key, and then encryption once again with a third key. The main disadvantage of 3DES is that it is slow when run in software. AES is the successor to DES (and 3DES), and is the result of an open competition run by NIST beginning in January 1997, and culminating in the selection of the Rijndael algorithm (one of the initial 15 candidate algorithms) as the AES. NIST used a number of evaluation criteria for the selection of the AES algorithm:
So, AES was designed from the ground up to be secure and computationally efficient (fast, with relatively low overhead). In addition, and with particular relevance for IPsec, AES offers fast key setup. Fast key setup is important to applications such as IPsec because keys can often change. The final encryption algorithm that you can use with your IPsec transform sets on Cisco routers is SEAL. SEAL is used with Stream Cipher ESP (SC/ESP), a nonstandard extension to ESP that enables the use of stream ciphers with IPsec. SEAL uses a 160-bit key, is optimized to run in software, but is not supported if a hardware encryption accelerator is present. SC/ESP (including when used with SEAL) mandates the use of authentication to prevent certain kinds of attacks that are specifically related to the use of stream ciphers with IPsec. If you attempt to configure SEAL without authentication, you will receive an error message. Two advantages of using SEAL encryption are its speed (SEAL is fastmeasured as being 16.9 times faster than DES in certain sample tests) and the reduced size of SEAL encrypted packets when compared to those encrypted using DES and AES. Selecting Compression in an IPsec Transform SetEncryption of plaintext produces a seemingly random ciphertext. Unfortunately, compression algorithms look for common patterns in data, and because a ciphertext by definition contains no common patterns, ciphertext cannot be compressed. In fact, compression of ciphertext can result in an expansion of the original data! The upshot of the fact that ciphertext cannot be compressed is that data link layer compression algorithms do not work with the network layer encryption provided by IPsec. So, is it possible to use compression with IPsec? Yes, compression is possible, but it must take place prior to encryption. The IP Payload Compression Protocol (IPComp or PCP) was designed to address the problem of the ineffectiveness of data link layer compression protocols when applied to encrypted data. When using PCP, data is compressed before it is encrypted. PCP, just like AH and ESP, is an IP protocol in its own right (IP protocol 108). Two compression algorithms are specified for use with PCP: Lempel-Ziv-Stac (LZS) and Deflate. On Cisco routers, you can configure LZS, which can give a maximum compression ratio of 2:1 depending on the data being compressed. The compression algorithm used between IPsec peers is negotiated using IKE, and this information is stored as a PCP SA. IPsec adds a large amount of overhead to a user packet (for more on this, see the section "Fragmentation Considerations in an IPsec VPN" in Chapter 7) and on low-speed lines this can cause a considerable impact on throughput. PCP may, therefore, be a solution for improving throughput on low-speed links. Note that some hardware accelerators support LZS; if LZS runs in software, however, it can add considerable processor overhead to an IPsec VPN gateway. Configuring IPsec Transform SetsUse the crypto ipsec transform-set transform-set-name transform1 [transform2] [transform2] [transform3] [tranform4] to configure transforms (IPsec cryptographic algorithms and parameters) for IPsec tunnels. It is possible to configure a total of four transforms (algorithms) within an IPsec transform set:
However, four transforms would necessarily include an AH (authentication) transform and an ESP authentication transform. Configuration of two authentication transforms within one transform set is nonsensical, and so the practical limit for the number of transforms within a transform set is three:
Cryptographic algorithms and parameters configured using the crypto ipsec transform-set command are used by the IPsec (and PCP) SAs negotiated during IKE phase 2. Table 6-6 summarizes IPsec transforms that you can configure using the crypto ipsec transform-set command.
Example 6-30 shows the configuration of a sample IPsec transform set with ESP SHA-1 authentication and ESP 128-bit AES encryption. Example 6-30. Sample IPsec Transform Set
It is worth noting the possible single transforms or combinations of transforms that you can use in a single transform set:
LZS compression can be used with all of these transforms. As you can see, it is possible to configure ESP, DES, or AES encryption without authentication in an IPsec transform set. Although this might be possible, it is not generally a good ideain certain circumstances ESP encryption SAs (without ESP or AH authentication) are vulnerable to cut-and-paste attacks. Cut-and-paste attacks involve the substitution of certain parts of IPsec packets and can result in an attacker being able to recover unencrypted messages (plaintext). So, use either ESP or AH authentication with ESP, DES, or AES encryption. There are also one or two transforms that you cannot use:
When configuring your IPsec transform sets, it is possible to configure the IPsec security protocol mode using the mode {tunnel | transport} command, as demonstrated in Example 6-31. Example 6-31. Configuring Security Protocol Modes
The highlighted line shows the specification of transport mode for use with IPsec transform set mjlnettransform. If you do not specify an IPsec security protocol mode, the default is tunnel mode. In tunnel mode, user packets are entirely encapsulated and protected by IPsec and a new IP header is added, whereas in transport mode the payload is encapsulated and protected by IPsec, but a new IP packet header is not added. Typically, tunnel mode is the mode used for IPsec VPNs, although transport mode may be used if a GRE tunnel is being used to carry multiprotocol and multicast traffic. See the section "Using GRE Tunnels to Carry Multiprotocol and Multicast Traffic Across the IPsec VPN" later in this chapter for more information on GRE tunnels. Designing and Configuring Crypto Access ListsIn IPsec, traffic selectors define the traffic that is to be protected by an SA. Traffic selectors consist of a number of items, including the following:
On Cisco routers, traffic selectors are configured using crypto access lists. Crypto access lists are extended access lists that are then specified in a crypto map. Example 6-32 shows a sample crypto access list. Example 6-32. Sample Crypto Access List
In Example 6-32, access list 101 specifies all IP traffic from source network 10.1.1.0/24 to destination network 10.2.2.0/24. In this case, all IP traffic from network 10.1.1.0/24 to network 10.2.2.0/24 will be protected using the algorithms specified in the IPsec transform set. Also, all IP traffic received from network 10.2.2.0/24 destined for 10.1.1.0/24 must be protected using the algorithms specified in the IPsec transform setif it is not, it will be dropped. The output of the show crypto ipsec sa command in Example 6-33 shows the IPsec SAs corresponding to the crypto access list configured in Example 6-32. Example 6-33. IPsec SAs with One Line in the Crypto Access List
Highlighted lines 1 and 2 show the traffic selectors configured in the crypto access list in Example 6-32. Highlighted lines 3 and 4 show the inbound ESP SA (with ESP AES encryption and SHA-1 authentication). Then, in highlighted lines 5 and 6, you can see the outbound ESP SA (again with AES encryption and SHA-1 authentication). It is a good idea to specify the traffic that you want to protect in as few lines as possible (often just one line). Each permit statement in a crypto access list causes separate SAs to be negotiated between IPsec peers. For example, the crypto access list shown in Example 6-34 results in the negotiation of the IPsec SAs shown in the output of the show crypto ipsec sa command in Example 6-35. Example 6-34. Crypto Access List with Two Lines
Example 6-35. IPsec SAs Corresponding to the Access List Shown in Example 6-34
Highlighted lines 1 and 2 in Example 6-35 show traffic selectors corresponding to the second line of the crypto access list in Example 6-34. Note the protocol (prot) and port numbers shown at the end of highlighted lines 1 and 2(/0/0). The 0s indicate that the traffic selectors specify IP but no specific IP protocol or port. Highlighted lines 3 and 4 show the ESP SAs associated with the traffic selectors specified in the second line of the crypto access list in Example 6-34. Then, in highlighted lines 5 and 6, you can see traffic selectors corresponding to the first line in the crypto access list. Notice the protocol and port (/1/0) at the end of highlighted lines 5 and 6. The 1 indicates the IP protocol number (ICMP). Finally, in highlighted lines 7 and 8, you can see the ESP SAs corresponding to the traffic selectors specified in the first line of the crypto access in Example 6-34. So, keep the number of crypto access list lines (permit statements) to a minimum or you will end up with unnecessary IPsec SAs between IPsec peers. It is worth saying that there are one or two reasons that might justify configuration of multiple permit statements in a crypto access listsee the section "Designing QoS for IPsec VPNs" in Chapter 7 on page 656 for more information. If you want to explicitly exclude some traffic from being protected by IPsec, just specify this traffic using a deny statement or statements at the beginning of your crypto access lists. Note that crypto access lists should be mirrored between peer IPsec VPN gateways. Example 6-36 shows the crypto access lists that would be configured on the London and Berlin gateways (refer back to Figure 6-31). Example 6-36. Crypto Access Lists Should Be Mirrored Between Peer IPsec VPN Gateways
It is actually possible to configure crypto access lists that are not mirrored between IPsec VPN gateways, but this results in just one IPsec VPN gateway being able to initiate an IPsec VPN tunnel, as well as IPsec traffic drops. Note For more information on crypto access lists that are not mirrored between peer IPsec VPN gateways (and the problems they can cause), refer to Chapter 8 of Troubleshooting Virtual Private Networks (Cisco Press). Troubleshooting Virtual Private Networks includes in-depth information on troubleshooting all typical and not-so-typical issues with IPsec VPNs. Pulling Everything Together with a Crypto MapNow that you have designed your IKE policies, IPsec transform sets, and crypto access lists, it is time to configure your crypto map. The function of the crypto map is to pull together the IKE policies, IPsec transform sets, and crypto access lists into a form that can then be applied to an interface. Example 6-37 illustrates the configuration of a crypto map using the crypto map map-name seq-num ipsec-isakmp [dynamic dynamic-map-name] [discover] command. Example 6-37. Configuration of a Crypto Map
In Example 6-37, a crypto map called mjlnetcmap is configured on IPsec VPN gateway London. Within the crypto map, the set peer [hostname | ip-address] command specifies the host name or IP address of the IPsec peer (in this case, IP address 192.168.2.2). The set transform-set transform-set-name [transform-set-name2.....transform-set-name6] then specifies that the IPsec transform set named mjlnettransform will be used to protect user traffic with peer 192.168.2.2. It is possible to specify up to six possible transform sets. If multiple transform sets are specified, a common transform set will be negotiated with the peer during IPsec tunnel setup (in IKE phase 2). Finally, the crypto access list is specified using the match address [access-list-number | name] command. In this example, access-list number 101 is specified. One other option that you can configure within a crypto map is PFS. Normally, keys used to encrypt and authenticate IPsec packets are derived from the IKE phase 1 Diffie-Hellman shared secret key. If the IKE phase 1 Diffie-Hellman shared secret key is discovered, this can lead to the compromise of all IPsec packets. If you specify PFS, however, a new Diffie-Hellman exchange takes place during IKE phase 2 (quick mode), and this exchange is used to derive the keys used to encrypt and authenticate IPsec packets. The result of using PFS is that the compromise of the IKE phase 1 Diffie-Hellman shared secret key cannot lead directly to the compromise of keys used to encrypt and authenticate IPsec packets. So, the advantage of PFS is increased security, but the disadvantage is some additional processing overhead whenever a new IPsec SA is negotiated during IKE phase 2. You can configure PFS using the set pfs [group1 | group2 | group5] under the crypto map, as shown in Example 6-38. Example 6-38. Configuring PFS Within the Crypto Map
Example 6-38 shows the configuration of PFS using Diffie-Hellman group 2 (1024 bit). If multiple IPsec peers connect over the same outside interface, you can specify multiple entries in a particular crypto map using different crypto map sequence numbers, as demonstrated in Example 6-39. Example 6-39. Configuration of Multiple Entries in a Crypto Map
After you have configured a crypto map, you can apply it to the (outside) interface to which IPsec peers will connect. Example 6-40 demonstrates application of a crypto map to an interface. Example 6-40. Application of a Crypto Map to an Interface
In Example 6-40, the crypto map is applied to the outside interface serial 1/0. Complete IPsec VPN Gateway ConfigurationsNow that you understand the main elements of the configuration of an IPsec VPN gateway, it is useful to take a look at the complete configurations of peer IPsec VPN gateways London and Berlin (see Example 6-41 and refer back to Figure 6-31). Example 6-41. Complete Configurations for IPsec VPN Gateways London and Berlin
Transporting Multiprotocol and Multicast Traffic over an IPsec VPNStandard IPsec can transport and protect unicast IP traffic, but it cannot at present natively transport and protect multiprotocol or multicast traffic. One workaround for this problem is to configure a GRE tunnel between peer IPsec VPN gateways. Multiprotocol and multicast traffic is transported over the GRE tunnel, and the GRE tunnel is in turn protected by IPsec. If you want to transport IP unicast and multicast traffic (but not multiprotocol traffic), another option is to configure virtual tunnel interfaces (VTI). VTIs were introduced in Cisco IOS Software Release 12.3(14)T. Configuring GRE/IPsec TunnelsFigure 6-37 illustrates an IPsec-protected GRE tunnel between IPsec VPN gateways. Figure 6-37. IPsec-Protected GRE Tunnel Between IPsec VPN Gateways
Configuration of IPsec-protected GRE tunnels involves the following steps:
These steps are discussed in detail in the following sections. Step 1: Configure the GRE Tunnel InterfacesThe first step is to configure the GRE tunnel interfaces on the IPsec VPN gateways. Example 6-42 shows the configuration of GRE tunnel interfaces on two IPsec VPN gateways depicted in Figure 6-37, London and Berlin. Example 6-42. Configuring GRE Tunnel Interfaces for Multiprotocol and Multicast Traffic Transport
The GRE tunnel interface is configured on the London gateway with a tunnel source IP address of 192.168.1.1 (its outside physical interface) and a destination IP address of 192.168.2.2 (the outside physical interface [tunnel source] on the Berlin gateway). The GRE tunnel interface on Berlin is configured in a similar manner. The tunnel source IP address is configured as 192.168.2.2 (its outside interface), and the tunnel destination IP address is 192.168.1.1 (the outside interface [tunnel source] on London). If you have multiple outside physical interfaces, you might want to configure a loopback interface (interface loopback interface-number) on each IPsec VPN gateway to act as the source address for the GRE tunnel. If you do use loopback interfaces as the source IP address of GRE tunnels, make sure that you specify the loopback interface on the IPsec VPN gateways using the crypto map crypto-map-name local-address interface (for example, crypto map mjlnetcmap local-address Loopback0) command to ensure that IKE negotiation succeeds between the IPsec VPN gateways. Also, if you are using preshared keys, make sure you specify the peer's loopback interface address using the crypto isakmp key key-string address peer-ip-address and crypto map set peer ip-address commands. Step 2: Configure the Routing Protocol or Static RoutesAfter you have configured the GRE tunnel interfaces, you can configure a routing protocol for IP reachability over the GRE tunnels between sites, as shown in Example 6-43. Example 6-43. Configuring EIGRP for IP Reachability Between IPsec VPN Sites
In Example 6-43, EIGRP is configured for IP reachability between the London and Berlin sites. In highlighted lines 1 to 3, EIGRP autonomous system 100 is configured on the London gateway, and EIGRP is enabled on the inside network (10.1.1.0/24) as well as on the GRE tunnel interface (10.3.3.0/24). Then, in highlighted lines 4 to 6, EIGRP autonomous system 100 is configured on Berlin, and EIGRP is enabled on the inside network (10.2.2.0/24) as well as on the GRE tunnel interface (10.3.3.0/24). The routing protocol should be enabled on the GRE tunnel interfaces and on inside interfaces (where appropriate), but it should not be enabled on the outside physical interface for reachability between tunnel endpoints. Note If the same routing protocol (instance) is configured on the GRE tunnel interface and on the outside physical interface (for reachability between the GRE tunnel endpoints), the GRE tunnel will be disabled. The GRE tunnel interface is disabled because the best route to the GRE tunnel destination is via the GRE tunnel itself, and the gateway attempts to send GRE tunnel packets over the GRE tunnel itself. That is not going to work! You could also choose to configure static IP routes for IP reachability between sites. In this case, you can configure the outbound interface of the static routes as the GRE tunnel interface, as shown in Example 6-44. Example 6-44. Configuring Static Routes for IP Reachability Between IPsec VPN Sites
In Example 6-44, highlighted line 1, a static route to the Berlin site network (10.2.2.0/24) via the GRE tunnel interface is configured on the London gateway. Then, in highlighted line 2, a static route to the London site network (10.1.1.0/24) via the GRE tunnel interface is configured on the Berlin site network. When you are choosing whether to use a dynamic routing protocol or static routes for IP reachability, remember that static routes are inherently unscalable. The administrative and management overhead of maintaining and troubleshooting a large number of static routes is often considered prohibitive. Step 3: Configure the IKE PoliciesAfter you have configured either a dynamic routing protocol or static routes, the next step is to configure the IKE (ISAKMP) policies on the gateways. There are no special considerations for GRE tunnels, and so the IKE policies should be configured as discussed in the section "Selecting and Configuring IKE Policies" earlier in this chapter. Step 4: Configure the IPsec Transform SetsNext are IPsec transform sets. You should configure these as described in the section "Selecting and Configuring IPsec Transform Sets" earlier in this chapter. It is worth noting that you can choose to configure IPsec transport mode when configuring IPsec protection for GRE tunnels. One advantage of using transport mode is that you save 20 bytes of overhead when compared to using tunnel mode because a new outer IP header is not required (compare Figures 6-14, 6-15, 6-19, and 6-20). Step 5: Configure the Crypto Access ListsFollowing the configuration of the IPsec transform sets, you can configure the crypto access list (see Example 6-45). Example 6-45. Configuring a Crypto Access List for a GRE Tunnel
Highlighted line 1 shows the crypto access list configured on London. Notice that the source and destination addresses (192.168.1.1 and 192.168.2.2, respectively) are the GRE tunnel endpoints (GRE tunnel interface source addresses). Also, notice that GRE is specified as the protocol within the crypto access list. In highlighted line 2, you can see the crypto access list on Berlin. The idea is the samesource and destination addresses correspond to the GRE tunnel endpoints. Again, GRE is specified as the protocol within the crypto access list. Step 6: Configure and Apply Crypto MapsTo a great extent, configuring and applying crypto maps is as described in the section "Pulling Everything Together with a Crypto Map." There is one important consideration, howeverif your gateways are running Cisco IOS Software prior to Release 12.2(13)T, you must apply the crypto map to the outside interfaces and the GRE tunnel interfaces. If your gateways are running Cisco IOS Software Release 12.2(13)T or higher, you need to apply the crypto map only to the outside physical interfaces. Note It is also possible to use the tunnel protection command to apply IPsec protection to a GRE tunnel. This command is discussed further in Chapter 7. Complete IPsec VPN Gateway Configurations with GRE Tunnel for Multiprotocol and Multicast Traffic TransportAgain, it is useful to examine the complete configurations of peer IPsec VPN gateways London and Berlin with GRE tunnel for multiprotocol and multicast traffic transport. Example 6-46 shows these configuration (see Figure 6-37 for the physical topology). Example 6-46. Complete Configurations for IPsec VPN Gateways London and Berlin with GRE Tunnels for Multiprotocol and Multicast Traffic Transport
Configuring VTIsThe configuration of VTIs is similar to that for IPsec-protected GRE tunnels. Example 6-47 shows the configuration on the Berlin and London IPsec VPN gateways using, in this case, preshared key authentication. Note that only the relevant configuration is shown. Example 6-47. Configurations for IPsec VPN Gateways London and Berlin with VTIs for IP Unicast and Multicast Traffic Transport
If you compare the configurations shown in Example 6-46 and 6-47, you will see quite a number of similarities. Apart from the obvious difference in the method of IKE phase 1 authentication (digital signature authentication versus preshared key authentication), the other major differences are the configuration of the VTIs and the IPsec profiles in Example 6-47. The configuration of the VTI consists of many of the same commands used to configure a GRE tunnel (tunnel source, tunnel destination, and so on). Some of the commands that are used to configure VTIs are new, however. The tunnel mode ipsec ipv4 command configures the tunneling mode as IPsec and the transport protocol as IPv4. The tunnel protection ipsec profile profile-name command associates the tunnel interface with an IPsec profile (which provides IPsec protection). The IPsec profile in this example is called vti.prof. The IPsec profile itself (vti.prof) is configured using the crypto ipsec profile profile-name command. Within the IPsec profile, an IPsec transform set (vti.trans) is specified using the set transform-set transform-set-name. The IKE policy, preshared key, and transform set (vti.trans) are configured in the normal way using the crypto isakmp policy, crypto isakmp key, and crypto ipsec transform-set commands. The show ip eigrp neighbors command can be used to verify the EIGRP neighbor relationship over the VTI (see Example 6-48). Example 6-48. Verifying the EIGRP Neighbor Relationship over the VTI Using the show ip eigrp neighbors Command
As you can see, IPsec VPN gateway London has an EIGRP neighbor relationship with IPsec VPN gateway Berlin (10.3.3.2) over the VTI (Tu0). As shown in Example 6-49, you can verity the PIM neighbor relationship using the show ip pim neighbor command. Example 6-49. Verifying the PIM Neighbor Relationship over the VTI Using the show ip pim neighbor Command
The output of the show ip pim neighbor command shows that a PIM neighbor relationship has also been established over the VTI with Berlin. Manual SA and Key ManagementAs discussed earlier in this chapter, there are two ways of managing SAs and session keys with IPsec:
Manual session key configuration does have a number of disadvantages, including the following:
Now that you know why you would not want to deploy it, it is worth taking a look at the one or two exceptions when the configuration of manual session keys might prove useful:
Okay, on to configuration. Figure 6-38 and Example 6-50 show the configuration of manual session keys on peer IPsec VPN gateways, London and Berlin. Figure 6-38. Configuring IPsec Manual Session Keys
Example 6-50. Configuring IPsec Manual Session Keys
The configuration of the London gateway begins with the command no crypto isakmp enable (highlighted line 1). This command disables IKE. In highlighted line 2, you can see a regular IPsec transform set. Note, however, that it only includes ESP DES encryption. You will know by now that this is a weak transformit specifies 56-bit DES (an insecure encryption algorithm), and it does not include authentication (it is vulnerable to cut-and-paste attacks). In a live network, you should include authentication in the transform set and if possible specify a stronger encryption algorithm. The crypto map map-name seq-number ipsec-manual command in highlighted line 3 is then used to specify that IKE will not be used to establish IPsec SAs. Within the crypto map, two session keys are specified using the set session-key {inbound|outbound} esp spi hex-key-string [authenticator hex-key-string] command (see highlighted lines 4 and 5). The set session-key command in highlighted line 4 configures the SPI (1000) and ESP key (1234567812345678) for IPsec packets inbound from the Berlin gateway to the London gateway. The SPI is specified in decimal (a value from 256 to 4,294,967,295), and the key is specified in hexadecimal. The set session-key command in highlighted line 5, on the other hand, configures the SPI (2000) and ESP key (8765432187654321) for IPsec packets sent by London and outbound to the Berlin gateway. Because ESP authentication is not specified in the IPsec transform in this example, the authenticator keyword is not required with the set session-key command. If you do specify ESP authentication, make sure that you configure the authenticator keyword and associated hex-key-string parameter. The authenticator keyword is used to configure the key string (in hexadecimal) to be used for ESP authentication. The key that you specify can be 8, 16, or 20 bytes long, depending on the following requirements:
If you configure AH in your IPsec transforms, you can specify the AH SPIs and keys in a similar way using the set session-key {inbound|outbound} ah spi hex-key-string command. The configuration of the Berlin gateway is almost identical, but there are one or two slight differences. The set session-key command in highlighted line 6 configures the SPI (2000) and ESP key (8765432187654321) for IPsec packets inbound from the London gateway. Parameters in this line must match those for IPsec packets outbound from the London gateway (see highlighted line 5). The set session-key command in highlighted line 5 configures the SPI (1000) and ESP key (1234567812345678) for IPsec packets sent by the Berlin gateway and outbound to the London gateway. Parameters in this line must match those for IPsec packets inbound to the London gateway (see highlighted line 4). So, configuration of manual session keys is fairly simple, but their usage is limited by the disadvantages discussed earlier in this section. Deploying IPsec VPNs with NAT/PATIf there is a Network Address Translation (NAT) or Port Address Translation (PAT) device in the path between IPsec peers in your IPsec VPN, you must carefully configure either the IPsec peers or the NAT/PAT device to ensure that IPsec operates correctly and does not break. This section examines how NAT/PAT devices can break IPsec, and how you can get around this. Figure 6-39 shows a sample IPsec VPN topology used to illustrate some of the concepts discussed in this section. Figure 6-39. Sample IPsec VPN Topology
As you can see in Figure 6-39, the only difference to the reference topology used throughout the rest this chapter is the addition of a NAT/PAT device in front of the London IPsec VPN gateway. How NAT/PAT Breaks IPsecSo, NAT can break IPsec, but how exactly can this happen? NAT/PAT can break IPsec in a number of ways, including the following:
To understand how you can get around problems with NAT/PAT, it is a good idea to examine each problem in a little more depth. NAT/PAT Can Cause IKE Negotiation Initiated by IPsec Peers on Outside Networks to FailNAT/PAT devices must be specifically configured to accept IKE negotiation initiated by IPsec peers on outside networks. This is because there is usually a default requirement with NAT devices that address translation be initiated by devices on the inside network. A simple method of allowing outsides IPsec devices to initiate IKE negotiation with inside IPsec devices when using standard (one-to-one) NAT is to configure a static NAT translation. So, for example, in Figure 6-39 a static translation would allow the Berlin gateway to initiate IKE negotiation through the NAT/PAT device to the London gateway. Example 6-51 shows the configuration of a static NAT translation to allow outside IPsec gateways to initiate IKE negotiation to an inside IPsec gateway. Example 6-51. Configuring a Static NAT Translation on the NAT Device to Allow Outside IPsec Gateways to Initiate IKE Negotiation with an Inside IPsec Gateway
The highlighted line shows a static NAT translation of London's inside local address (10.10.10.1) to the inside global address 192.168.3.5. Do not forget to configure the remote gateway (Berlin in this example) to use the local gateway's inside global address as appropriate (see Example 6-52). Example 6-52. Configuring the Remote Gateway (Berlin) to Use the Local Gateway's Inside Global Address
In Example 6-52, highlighted line 1, the inside global address of London gateway (192.168.3.5) is specified using the crypto isakmp key and set peer commands. If you are using PAT rather than standard (one-to-one) NAT, the configuration differs slightly, as shown in Example 6-53. Example 6-53. Configuring a Static Translation on a PAT Device to Allow Outside IPsec Gateways to Initiate IKE Negotiation with an Inside IPsec Gateway
The ip nat inside source static esp inside_local_address_of_gateway interface outside_interface command in highlighted line 1 is used to allow the translation of ESP tunnel mode traffic for an IPsec tunnel to the specified inside local address. So, in this example, the destination address of ESP packets that the Berlin gateway sends to the London gateway is translated from the inside global address 192.168.3.1 (the IP address applied to interface serial 2/1) to the inside local address 10.10.10.1 (London's outside interface IP address). The ip nat inside source static udp inside_local_address_of_gateway 500 interface outside_interface 500 command (highlighted line 2) similarly allows the translation of ISAKMP traffic (UDP port 500) to the specified inside local address. In this example, the destination address of ISAKMP packets that the Berlin gateway sends are translated from the inside global address 192.168.3.1 (the IP address applied to interface serial 2/1) to the inside local address 10.10.10.1 (London). Again, you should configure the remote gateway to use the local gateway's inside global address as appropriate (see Example 6-52). In this case, the local gateway's inside global address is 192.168.3.1 (the IP address of interface serial 2/1 on the NAT device [see Example 6-53]). NAT/PAT Can Cause Rekeying to Fail When NAT/PAT Is Based on IKE CookiesInstead of translating UDP ports, some NAT/PAT devices use ISAKMP cookies to demultiplex IKE traffic inbound on the outside interface and identify individual IPsec peers to which this traffic is bound. Cookies are unique identifiers used during IKE phase 1 to make denial-of-service attacks more difficult. If a NAT/PAT device uses ISAKMP cookies to demultiplex IKE traffic, then during rekeying (when different cookies are typically used) NAT/PAT may fail. NAT/PAT Might Break IP Address IKE Identifier VerificationWhen you use IP addresses as IKE (ISAKMP) identifiers, your IKE identifier verification might fail, and ISAKMP packets might be dropped. Verification might fail because NAT/PAT modifies IP addresses in the IP header. NAT/PAT Can Cause IPsec Peers to Drop ISAKMP TrafficWhen there are multiple IPsec peers behind a PAT device, all of which are negotiating IKE SAs to the same responder, that responder must be able to accept ISAKMP packets with a source port other than UDP port 500 if the PAT device translates the source port of ISAKMP packets (from UDP port 500). This is because the PAT device translates the source UDP port of ISAKMP packets from each IPsec peer to a unique value (so that it can distinguish the individual flows/IPsec peers). However, translation of UDP source ports does mean that the responder must be able to accept (and respond to) ISAKMP packets from source UDP ports other than UDP port 500. During rekeying, the responder must also use the unique UDP port that identifies each individual IPsec peer behind the PAT device as the UDP destination port for ISAKMP packets. If the responder does not do this, rekeying may fail. Figure 6-40 illustrates translation of the UDP port for ISAKMP packets. In Figure 6-40, the UDP port for ISAKMP packets from hosts A, B, and C (all IKE initiators) is translated from port 500 to X, Y, and Z, respectively. This translation of UDP source port numbers allows the PAT device to distinguish ISAKMP traffic inbound from the IKE responder. Figure 6-40. PAT Device Translates ISAKMP Source Port Numbers
So, for example, when IKE traffic from Host A to the IKE responder is received on the PAT device, it translates the UDP source port from 500 to X. The IKE responder then sends IKE traffic to Host A using UDP destination port X, and because this UDP port is unique, the PAT device is able to distinguish that this traffic should be sent to Host A (and not Hosts B and C). It is worth noting that some PAT devices do not translate UDP port 500 because of the inability of some IPsec devices to handle ISAKMP traffic on UDP ports other than 500. NAT/PAT Causes IPsec Devices to Drop All AH TrafficIf AH is used to protect IP traffic (whether in transport or tunnel mode), the whole packet is authenticated, including the outer IP header. NAT/PAT, by definition, translates the outer header IP address(es), and that causes the AH integrity check to fail. Figure 6-41 illustrates the failure of the AH integrity check. Figure 6-41. NAT Causes the AH Integrity Check to Fail
In Figure 6-41, the London gateway sends an AH packet to the Berlin gateway. The NAT/PAT device in the path translates the IP address(es) in the outer IP header, and when the AH packet arrives at the Berlin gateway, this translation causes the AH integrity check to fail, and the Berlin gateway drops the packet. So, if there is a NAT/PAT device between two IPsec devices, use ESP rather than AH. NAT/PAT Based on SPI Selection Might Break IPsecAs previously discussed, a combination of the security protocol (AH or ESP), SPI, and destination address uniquely identifies an IPsec SA. NAT/PAT devices sometimes use the SPI of ESP packets to distinguish traffic flows from multiple IPsec peers and ensure that IP addresses are correctly translated. NAT/PAT based on the SPI of ESP packets often works well, but it can sometimes go wrong. Before examining how it can go wrong, it is useful to first examine exactly how NAT/PAT based on SPI works. SPIs are assigned independently by the IPsec devices and then communicated to IPsec peers during IKE phase 2 (quick mode) negotiation. So, one host will inform the other of the SPI to use when sending traffic to it for a particular IPsec SA. Because all phase 2 messages are encrypted, it is impossible for a PAT device to find out SPI values from IKE negotiation. PAT devices can translate the IP addresses for ESP packets by making a "best guess" based on which inside host (or other device) has recently negotiated IKE and sent ESP packets. Figure 6-42 illustrates how a PAT device can handle ESP packet translation using SPIs. In Figure 6-42, Host A negotiates IKE with the IPsec gateway. During phase 2 negotiation, Host A informs the IPsec gateway that it should use SPI 0x11111111 when sending ESP packets to Host A, and the IPsec gateway informs Host A that should use SPI 0x22222222 when sending ESP packets to the IPsec gateway. The phase 2 negotiation is encrypted so the PAT device has no way of knowing that Host A has assigned SPI 0x11111111 and that the IPsec gateway has assigned SPI 0x22222222. Figure 6-42. NAT/PAT Based on SPIs
After IKE negotiation is finished, Host A sends an ESP packet to the IPsec gateway (using SPI 0x22222222). Then shortly after that, the IPsec gateway sends an ESP packet to Host A via the PAT device. When the PAT device receives the ESP packet, the destination IP address is 192.168.1.1 (the PAT overload IP address), and the SPI is 0x11111111. The PAT device then does a lookup into its translation table for the SPI (and IP addresses). If the PAT device has not previously seen the SPI, it makes a best guess and assumes that this SPI corresponds to an IPsec SA negotiated via a recent IKE negotiation (in this case, between Host A and the IPsec gateway). Having determined that the ESP packet should go to Host A, the PAT device translates the destination IP address of the ESP packet from 192.168.1.1 (the inside global address) to 10.1.1.1 (the inside local address [Host A]) and sends the packet onward to Host A. So, NAT/PAT based on SPIs can work well. But if two (or more) inside IPsec devices attempt to negotiate IKE with the same peer IPsec device at the same time, this can lead to communication failure. Figure 6-43 illustrates a communication failure when two devices on the inside of the PAT device simultaneously attempt to negotiate IKE with the same IPsec peer. In Figure 6-43, Hosts A and B simultaneously negotiate IKE with the IPsec gateway. During IKE phase 2 negotiation, Host A informs the IPsec gateway that it should use SPI 0x11111111 when transmitting ESP packets to Host A. Host B informs the IPsec gateway that it should use SPI 0x55555555 when transmitting ESP packets to Host B. Immediately after negotiating IKE phase 2, Hosts A and B both send ESP packets to the IPsec gateway (not shown). Figure 6-43. NAT/PAT Based on SPIs Fails
The IPsec gateway then sends an ESP packet to Host A, the header of which contains SPI 0x11111111. When it arrives at the PAT device, the PAT device looks up the SPI in its translation table, and when it finds no existing translation for that particular SPI (from that particular IPsec gateway), the PAT device checks to see which inside devices have recently negotiated IKE with the IPsec gateway. Unfortunately, both Host A and Host B have recently negotiated IKE phase 2 with the IPsec gateway, and so the PAT device has no idea where to send the packet. NAT/PAT Devices Might Not Translate ESP PacketsSome NAT/PAT devices will only translate UDP- or TCP-based traffic. In this case, ESP traffic will simply be dropped. NAT/PAT Translation Timeouts Can Cause IPsec Traffic to be DroppedNAT translations may time out before IPsec SAs. In this case, IPsec traffic will be black-holed! Figure 6-44 illustrates IPsec packets dropped when the NAT translation times out before the IPsec SA. Figure 6-44. NAT Translation Times Out Before the IPsec SA
In Figure 6-44, the London and Berlin gateways negotiate IKE and then exchange ESP packets. At this point, NAT translations exist on the NAT device for IPsec traffic between the London and Berlin gateways. A period of inactivity then ensues, during which no traffic is sent between the London and Berlin gateways. This period of inactivity causes the NAT translations on the NAT device to time out. The Berlin gateway then sends an IPsec packet to the London gateway, but the NAT device drops the packet because the NAT translation has already timed out. NAT/PAT Can Cause TCP/UDP Header Checksum Verification to Fail When TCP/UDP Traffic Is Transported over ESPTCP and UDP include a checksum to ensure the integrity of segments transmitted over a network. The checksum computation performed by TCP and UDP includes not only the TCP or UDP header and data but also a 12-byte "pseudo-header." This pseudo-header includes the source and destination IP addresses and ensures the TCP or UDP segment has not been delivered to the wrong destination. Normally, when a NAT device modifies IP addresses in the IP header, it updates the TCP checksum as appropriate. In transport mode IPsec, the pseudo-header included in checksum calculation includes IP addresses from the outer IP header. Unfortunately, when a NAT device translates IP addresses in the outer header, it cannot update the checksums in the TCP or UDP headers because they are protected by ESP. This means that checksum verification fails on the receiving IPsec peer, and packets may be dropped. NAT/PAT Can Cause Applications with Embedded IP Addresses to FailIf IP addresses are embedded into the payload of an IP packet and the packets are protected by ESP, the IP addresses embedded in the payload will not be translated by a NAT/PAT device, and applications that rely on the IP addresses in the payload being correctly translated will not function correctly. FTP is a good example of a protocol where IP addresses are carried in the payload of the packet (with FTP PORT and PASV commands). Figure 6-45 shows how IP addresses embedded in an ESP packet payload are not translated by a NAT device. Figure 6-45. IP Addresses Embedded in IPsec Packet Payloads Are Not Translated by NAT
In Figure 6-45, the FTP server sends an ESP packet to the FTP client. The NAT device translates the source address of the packet from 10.1.1.1 to 192.168.3.1 but is unable to modify the IP address (10.1.1.1) embedded in the ESP packet payload. Because the NAT device does not translate the embedded IP address, communication fails. Unintentional NAT'ing of User Packets Can Cause These Packets Not to Be Sent over the IPsec TunnelIf you configure NAT on an IPsec VPN gateway, you must be careful not to unintentionally NAT user packets that should be sent over an IPsec tunnel. In this case, user packets may not be sent over the tunnel, as illustrated in Figure 6-46. Figure 6-46. Unintentionally NAT'ing User Packets Causes Them Not to Be Sent over the IPsec Tunnel
In Figure 6-46, (inbound) user traffic from the Berlin site is sent over the IPsec tunnel and successfully received at the London site. No user traffic from network 10.1.1.0/24 to network 10.2.2.0/24 is sent over the IPsec tunnel, however. Example 6-54 shows the configuration of the London gateway. Only the relevant configuration is shown. Example 6-54. London Gateway's Configuration
As you can see in highlighted lines 1 and 3, the crypto access list (101) specifies that all user (IP) traffic outbound from network 10.1.1.0/24 to network 10.2.2.0/24 should be sent over the IPsec tunnel. But, no traffic outbound from network 10.1.1.0/24 to network 10.2.2.0/24 is being sent over the IPsec tunnel, as shown in the output of the show crypto engine connections active command (see Example 6-55). Example 6-55. No Outbound Traffic Is Sent over the IPsec Tunnel
The first highlighted line shows the inbound IPsec SA corresponding to the IPsec tunnel. As you can see, 45 packets have been decryptedthese are inbound user packets from the Berlin site (10.2.2.0/24). The second highlighted line shows the outbound IPsec SA corresponding to the IPsec tunnel. No user packets from network 10.1.1.0/24 to network 10.2.2.0/24 have been sent using this IPsec SA (this is indicated by the 0 in the Encrypt column). The reason that no user traffic (from network 10.1.1.0/24 to network 10.2.2.0/24) has been sent outbound over the IPsec tunnel is revealed if you take a look back at highlighted lines 2 and 4 in Example 6-54. Highlighted line 2 in Example 6-54 shows that the source IP address of all user traffic specified in access list 102 (shown in highlighted line 4 in Example 6-54) is translated to the IP address configured on interface serial 1/0 (192.168.1.1). The crypto access list specifies that all user traffic from (source) network 10.1.1.0/24 to (destination) network 10.2.2.0/24 should be sent over the IPsec tunnel, but the NAT source list specifies that the source IP address of all user traffic from source 10.1.1.0/24 should be translated to IP address 192.168.1.1. Unfortunately, NAT happens before IPsec, so by the time any user traffic from source network 10.1.1.0/24 is matched against the crypto access list, the source IP address has already been translated (to 192.168.1.1), it does not match the source addresses in the crypto access list (10.1.1.0/24), and it is therefore not sent over the IPsec tunnel. To solve this issue, when configuring NAT on an IPsec gateway, you must be careful to ensure that user traffic that should be sent over that IPsec tunnel is not unintentionally NAT'ed. Access list 102 (which defines addresses to be NAT'ed [see highlighted line 4, Example 6-54]) is then modified to ensure that user traffic from network 10.1.1.0/24 to network 10.2.2.0/24 is sent over the IPsec tunnel, as shown in Example 6-56. Example 6-56. Bypassing NAT for User Traffic from Network 10.1.1.0/24 to Network 10.2.2.0/24
In highlighted line 1, access list 102 is deleted. Then, in highlighted lines 2 and 3, access list 102 is reconfigured to deny user traffic from network 10.1.1.0/24 to network 10.2.2.0 (the user traffic specified in the crypto access list [see Example 6-54, highlighted line 3]), and permit all other user traffic from network 10.1.1.0/24. The effect of this reconfiguration is that user traffic that should be sent over the IPsec tunnel (as defined in the crypto access list) bypasses NAT. Because this user traffic bypasses NAT, it now correctly matches the crypto access list and is sent over the IPsec tunnel. All other user traffic from network 10.1.1.0/24 to any other destination is still NAT'ed. In Example 6-57, the output of the show crypto engine connections active command shows that outbound traffic from the network 10.1.1.0/24 to network 10.2.2.0/24 is now sent over the IPsec tunnel. Example 6-57. Outbound Traffic from Network 10.1.1.0/24 to Network 10.2.2.0/24 Is Now Sent over the IPsec Tunnel
The first highlighted line shows inbound user traffic that has been sent over the IPsec tunnel from the Berlin site (121 packet decrypted). The second highlighted line shows outbound user traffic that has been sent over the IPsec tunnel to the Berlin site (121 packet encrypted). Figure 6-47 illustrates the effect of modifying access list 102. Figure 6-47. User Traffic from Network 10.1.1.0/24 to Network 10.2.2.0/24 Is Now Sent over the IPsec Tunnel
So, now you know how to bypass dynamic NAT for user traffic that should be sent over an IPsec tunnel. But, how about bypassing static NAT? Example 6-58 shows the configuration necessary to bypass static NAT for user traffic that should be sent over an IPsec tunnel. This configuration relates to the topology shown in Figures 6-46 and 6-47. Example 6-58. Bypassing Static NAT for User Traffic That Should Be Sent over the IPsec Tunnel
The static NAT entry in highlighted line 3 specifies that the source address 10.1.1.2 should be translated to address 192.168.1.3. Route map bypass.static.nat in highlighted lines 5 through 7 ensures that all traffic matching access list 103 (highlighted line 4) should be routed via the IP address 100.1.1.2 (an IP address on the same subnet as interface Loopback 0 [see highlighted line 1]). The route map is then applied to the inside interface in highlighted line 2. Now, the effect of routing all user traffic matching access list 103 (host address 10.1.1.2 to network 10.2.2.0/24) via next hop 100.1.1.2 is that this traffic bypasses the static NAT entry (highlighted line 3). The user traffic specified in access list 103 then matches the crypto access list (which matches all traffic from network 10.1.1.0/24 to network 10.2.2.0/24), and it is sent over the IPsec tunnel. Getting Around Issues with NAT/PAT and IPsec TunnelsAs described in the previous sections, NAT/PAT can break IPsec in a number of ways. This section describes and summarizes possible solutions that will allow you configure IPsec tunnels when there is a NAT device in the path between IPsec peers. To allow IPsec tunnels to traverse NAT/PAT devices, you can do the following:
Allowing IPsec to Traverse a FirewallIf there is a firewall in front of an IPsec VPN gateway (as shown in Figure 6-48), you must be careful to ensure that IPsec traffic is allowed through the firewall. Figure 6-48. Firewall in Front of an IPsec VPN Gateway
The protocols and ports that you might need to allow through a firewall (depending on your precise configuration) are as follows:
|
|
|
