IPsec in Firewalled Environments
IPsec in NAT Environments
IPsec and Quality of Service
IPsec and Fragmentation
IPsec and Recursive Routing
IPsec Diagnostic Tools within Cisco IOS
The most commonly used categories of diagnostic tools used within Cisco IOS are show and debug commands. Throughout the course of this chapter, we will use variations of these two command sets to diagnose issues commonly found within Cisco IOS. As we've discussed, there are detailed steps that occur during the formation of Internet Security Association and Key Management Protocol (ISAKMP) and IPsec negotiation between two IPsec VPN endpoints. We will examine common errors in these steps through execution of the following debugging commands within IOS:
debug crypto isakmp
debug crypto IPsec
Additionally, we will explore several show commands necessary to uncover common errors and performance issues related to the negotiate of IPsec VPN tunnels, including fragmentation/maximum transmission unit (MTU) issues, quality of service (QoS) issues, Network Address Translation (NAT) issues, and issues relating to recursive routing. A subset of the commands we will discuss to address these issues includes:
show crypto isakmp sa
show crypto isakmp sa nat
show crypto IPsec sa
show crypto engine connections active
show crypto engine connections dropped-packet
show crypto engine connections flow
show crypto engine qos
Common Configuration Issues with IPsec VPNs
There are many parameters and features to understand when deploying IPsec VPNs. In this section, we will discuss configuration issues presented when one or more IPsec VPN gateways are configured incorrectly. After discussing the nature of each of the above commonly experienced IPsec VPN configuration issues, we will discuss the methods used to effectively diagnose and remedy these issues.
IKE SA Proposal Mismatches
Unless IPsec session keys are manually defined, two crypto endpoints must agree upon an ISAKMP policy to use when negotiating the secure Internet Key Exchange (IKE) channel, or ISAKMP security association (SA). As such, when two VPN endpoints fail to agree upon a usable ISAKMP policy, IPsec SA negotiation cannot initiate, and traffic will continue to flow unencrypted.
Figure 2-24 and Figure 2-25 provide a brief description of ISAKMP policy negotiation process in main mode and aggressive mode respectively and the involved configuration on two VPN endpoints. Also remember from our discussions in Chapter 2 that ISAKMP policies are listed in order of priority (the lower number being the highest priority). The initiator will offer the highest priority proposal, and the responder will search its locally configured ISAKMP policies for a match. If there are none, the initiator will propose the next highest ISAKMP policy and define its local configuration. This process will continue until the initiator has no proposals left to offer the responder. The result, in this case, would be an ISAKMP SA proposal mismatch. Using the configurations provided in Example 4-1 and Example 4-2, Router_A and Router_B will attempt to form an IKE SA between one another using the topology illustrated in Figure 4-1.
ISAKMP SA Negotiation Resulting in ISAKMP Proposal Mismatch
Example 4-1 provides the ISAKMP policies configured for Router_A in Figure 4-1. Note that, in this configuration, there are no ISAKMP proposals configured that match those configured on Router_B in Example 4-2.
Example 4-1 Crypto ISAKMP Policy Definition for Router_A in Figure 4-1 (Mismatch with Router_B, Example 4-2)
Router_A#show crypto isakmp policy
Global IKE policy
Protection suite of priority 10
encryption algorithm: Three key triple DES
hash algorithm: Message Digest 5
authentication method: Pre-Shared Key
Diffie-Hellman group: #2 (1024 bit)
lifetime: 86400 seconds, no volume limit
Protection suite of priority 20
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Pre-Shared Key
Diffie-Hellman group: #2 (1024 bit)
lifetime: 86400 seconds, no volume limit
Protection suite of priority 30
encryption algorithm: AES - Advanced Encryption Standard (128 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
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
Example 4-2 provides the ISAKMP policy configuration on Router_B of Figure 4-1. Router_B will use this policy when building an ISAKMP SA to Router_A, whose ISAKMP policy is provided in Example 4-1. Because Router_B's ISAKMP configuration contains no matching proposals with Router_A's configuration provided in Example 4-1, ISAKMP negotiation will fail.
Example 4-2 Crypto ISAKMP Policy Definition for Router_B in Figure 4-1 (Mismatch with Router_B, Example 4-1)
Router_B#show crypto isakmp policy
Global IKE policy
Protection suite of priority 10
encryption algorithm: AES - Advanced Encryption Standard (128 bit keys).
hash algorithm: Message Digest 5
authentication method: Pre-Shared Key
Diffie-Hellman group: #5 (1536 bit)
lifetime: 86400 seconds, no volume limit
Protection suite of priority 20
encryption algorithm: Three key triple DES
hash algorithm: Message Digest 5
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit
Protection suite of priority 30
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Pre-Shared Key
Diffie-Hellman group: #2 (1024 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
The following numbered sequence of events describes the ISAKMP proposal mismatch between the configurations provided in Example 4-1 for Router_A in Figure 4-1 and Example 4-2 for Router_B in Figure 4-1.
Router A sends its configured ISAKMP policies 10, 20, and 30 to Router B.
Router B checks policy 10 obtained in step 1 against its own configured policies, beginning with the lowest numbered policy and ending with the highest.
If Router B does not find a match in step 2, it checks policy 20 obtained in step 1 against its own configured policies, starting with the lowest numbered and ending with the highest.
If Router B does not find a match in step 3, it checks policy 30 obtained in step 1 against its own configured policies, starting with the lowest numbered and ending with the highest.
If Router B does not find a match in step 4, then a proposal mismatch has occurred, and the Phase 1 negotiation times out.
In order to confirm that IKE proposal mismatches have occurred in an IPsec VPN tunnel negotiation, we will inspect the output of the ISAKMP SA negotiation between Routers A and B. Routers A and B are using preshared IKE authentication in a site-to-site VPN, but have not been configured with matching ISAKMP policies. We will execute the command debug crypto isakmp on routers A and B to highlight that an IKE proposal mismatch is indeed the cause of ISAKMP SA negotiation failure. Example 4-3 displays debugging output as ISAKMP policies proposed by Router_A are checked against locally configured policies on Router_B.
In the diagnostic output shown in Example 4-3, Router_B checks proposals sent from Router_A for potential matches. Router_B begins by checking the ISAKMP proposals sent from Router_A against its own configured ISAKMP proposals. It does this by checking all of the proposals received (starting with lowest numbered and ending with highest) against favored policy (lowest numbered). If there are no matches, it checks the received policies in the same order against its next-lowest-numbered policy. This process continues until a match is found or all policies have been checked and no match has been found. In this specific proposal, the encryption proposed for encrypting the IKE channel does not match (see Examples 4-2 and 4-3 for ISAKMP proposal information for Router_A and Router_B), and Router B continues to check other offered proposals against its locally configured ISAKMP policies. Example 4-3, line 12, confirms that a proposal mismatch has occurred. Router_B finds that no ISAKMP proposals sent from Router_A match its own configured ISAKMP policies and therefore deletes the Phase1 SA and Phase1 negotiation times out on Router_A, as confirmed in Example 4-3, line 18.
Example 4-3 Isolating IKE Proposal Mismatches on the Initiating VPN Endpoint (Router A)
1 Router_B#debug crypto isakmp 2 Crypto ISAKMP debugging is on 3 ! 4 ! 5 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):Checking ISAKMP transform 1 against priority 10 policy 6 *Feb 16 12:11:02.379: ISAKMP: encryption 3DES-CBC 7 *Feb 16 12:11:02.379: ISAKMP: hash MD5 8 *Feb 16 12:11:02.379: ISAKMP: default group 2 9 *Feb 16 12:11:02.379: ISAKMP: auth pre-share 10 *Feb 16 12:11:02.379: ISAKMP: life type in seconds 11 *Feb 16 12:11:02.379: ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 12 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):Encryption algorithm offered does not match policy! 13 ! 14 ! 15 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):no offers accepted! 16 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0): phase 1 SA policy not acceptable! (local 200.0.0.2 remote 200.0.0.1) 17 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):peer does not do paranoid keepalives. 18 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):deleting SA reason "Phase1 SA policy proposal not accepted" state (R) MM_NO_STATE (peer 200.0.0.1)
Until the two endpoints can agree on an ISAKMP policy to use when securing the IKE channel and negotiating a Diffie-Hellman key to use when encrypting the IKE exchanges and in the IPsec transform, IPsec VPN tunnel negotiation cannot continue. Another task that must be performed successfully for IPsec VPN tunnel negotiation to continue is IKE authentication.
IKE Authentication Failures and Errors
Recall from our previous discussions that, in Cisco IOS, there are three methods offered to authenticate peers wanting to negotiate an ISAKMP SA: preshared keys (PSKs), RSA signatures, or RSA encryption. As we had discussed in Chapter 2, all three authentication methods have distinct elements used when authenticating IKE Peers. We will discuss common IKE authentication failure issues within the context of each of these three authentication methods.
IKE Authentication Errors and PSKs
There are two conditions that must be met for two IPsec VPN endpoints to authenticate each other using IKE PSKs. First, matching keys must be configured on the two endpoints. Second, the endpoints must be configured to share these keys with the correct peer. Router_A and Router_B are now configured with matching ISAKMP policies for Phase 1 negotiation, but still have problems preventing them from authenticating one another. We will examine debugging output on the routers in Figure 4-2 to highlight authentication failures directly attributable to mismatched keys and mismatched peers.
Troubleshooting IKE PSK Authentication
Example 4-4 provides the configuration of Router_A in Figure 4-2. Note that, unlike Router_A's configuration in Figure 4-1, Router_A is now configured with an ISAKMP policy that contains a matching proposal (Example 4-4, priority 30) with Router_B (Example 4-5, priority 10). In this case, however, IKE will still fail to negotiate due to a mismatched PSK on Router_A (Example 4-4, line 32) and Router_B (Example 4-5, line 32).