Case Studies
This section contains some troubleshooting issues that are slightly more uncommon than those contained in the main section on troubleshooting IPSec VPNs.
Topics covered in this section include CA server authentication and enrollment issues, together with VPN client IKE negotiation issues.
CA Authentication or Enrollment Fails
If you are using a certificate server for certificate distribution, you will need to authenticate the CA server and then enroll your router with the CA to obtain a certificate. A number of issues can, however, cause authentication or enrollment to fail.
In this case study, the network administrator at the Tokyo site is attempting to obtain a certificate for the local router.
In Example 8-98, the administrator attempts to authenticate the CA by obtaining the CA server certificate from the server.
Example 8-98. CA Authentication Fails
Tokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#crypto ca authenticate mjlnetca % CA Cert not yet valid or is expired - start date: 15:11:14 GMT Mar 14 2003 end date: 15:19:53 GMT Mar 14 2005 % Error processing Certificate Authority certificate. Tokyo(config)#exit Tokyo# |
In highlighted line 1, the administrator issues the command to obtain the CA certificate and authenticate the CA server. Then in highlighted line 2, the router reports that the CA's certificate is not yet valid or is expired.
If you examine highlighted lines 3 and 4, you can see that the CA certificate's start date is March 14 2003, and the end date is March 14 2005. The message in highlighted line 2, therefore, indicates that the time on the router is outside this range.
The problem is soon revealed when the router's clock is examined using the show clock command, as shown in Example 8-99.
Example 8-99. Tokyo's Clock Is Incorrect
Tokyo#show clock 21:02:48.563 GMT Sun Jun 27 2025 Tokyo# |
As you can see, someone has incorrectly set Tokyo's clock. In this case, because NTP is not being used, the clock can be reset locally on Tokyo using the clock set command. This is demonstrated in Example 8-100.
TIP
If your routers do not have hardware clocks, every time they are rebooted the clock will be reset—this is a good reason to use NTP instead.
Example 8-100. Tokyo's Clock Is Reset
Tokyo#clock set 21:01:00 14 march 2003
|
Once Tokyo's clock has been reset, CA authentication, together with enrollment for Tokyo, succeeds. This is shown in Example 8-101.
Example 8-101. CA Authentication and Enrollment Succeed
Tokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#crypto ca authenticate mjlnetca Certificate has the following attributes: Fingerprint: 9C514FE0 A4A56F42 8612D771 6AC073FC % Do you accept this certificate? [yes/no]: yes Tokyo(config)# Tokyo(config)#crypto ca enroll mjlnetca % % Start certificate enrollment .. % Create a challenge password. You will need to verbally provide this password to the CA Administrator in order to revoke your certificate. For security reasons your password will not be saved in the configuration. Please make a note of it. Password: Re-enter password: % The subject name in the certificate will be: Tokyo.mjlnet.com % Include the router serial number in the subject name? [yes/no]: yes % The serial number in the certificate will be: 0168FEB5 % Include an IP address in the subject name? [yes/no]: yes Interface: serial4/0 Request certificate from CA? [yes/no]: yes % Certificate request sent to Certificate Authority % The certificate request fingerprint will be displayed. % The 'show crypto ca certificate' command will also show the fingerprint. Tokyo(config)# Fingerprint: C51338A8 62CA6739 6E88718E CC574ACF Tokyo(config)# 00:13:27: CRYPTO_PKI: status = 102: certificate request pending 00:13:36: CRYPTO_PKI: status = 102: certificate request pending 00:14:39: %CRYPTO-6-CERTRET: Certificate received from Certificate Authority Tokyo(config)#exit Tokyo# |
In highlighted line 1, CA authentication is attempted using the crypto ca authenticate command. Then in highlighted line 2, the administrator is asked to accept the CA's certificate (which he does), indicating that the CA's certificate has been successfully downloaded and accepted. Finally, in highlighted lines 3 and 4, the administrator enrolls Tokyo with the CA and receives a certificate.
Successful enrollment is confirmed using the show crypto ca certificates command, as shown in Example 8-102.
Example 8-102. Tokyo Has Successfully Enrolled
Tokyo#show crypto ca certificates Certificate Status: Available Certificate Serial Number: 1135294300000000000A Key Usage: General Purpose Issuer: CN = mjlnetca OU = mjlnet O = MJL Network Services L = London ST = London C = UK EA =<16> [email protected] Subject Name Contains: Name: Tokyo.mjlnet.com IP Address: 172.16.5.1 Serial Number: 0168FEB5 CRL Distribution Point: http://markacs/CertEnroll/mjlnetca.crl Validity Date: start date: 20:52:50 GMT Mar 14 2003 end date: 21:02:50 GMT Mar 14 2004 Associated Identity: mjlnetca |
As you can see, a certificate for Tokyo has been obtained from the CA. This is indicated by the certificate's available status (highlighted line 1). The issue is resolved.
Numerous of other issues can cause CA authentication or enrollment to fail. Some of these are as follows:
The crypto ca trustpoint or ca identity parameters are misconfigured.
If any of the trustpoint or ca identity parameters are misconfigured, there may be problems with certificate enrollment.
See the section “Configuring Site-to-Site IPSec VPNs with Digital Certificates” on page 677 for more details.
The CA server is unreachable on TCP port 80 (HTTP) or UDP port 69 (TFTP).
Ensure that the CA server is reachable via TCP port 80 from the router if you are using HTTP for certificate enrollment.
If you are using TFTP, then ensure that the server is reachable via UDP port 69. If the server is unreachable from the router CA server authentication and enrollment will fail.
Note that the following error message is logged if the server is unreachable during CA server authentication:
Tokyo(config)#crypto ca authenticate mjlnetca % Error in receiving Certificate Authority certificate: status = FAIL, cert length = 0 Tokyo(config)#
If reachability to the CA server fails during enrollment, the following message is displayed by the debug crypto pki transactions command:
Tokyo#debug crypto pki transactions Crypto PKI Trans debugging is on Tokyo# Tokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#crypto ca enroll mjlnetca 03:42:36: CRYPTO_PKI: status = 0: failed to open http connection
Note that only the relevant portion of the output is shown.
Certificate enrollment is rejected.
If the CA server rejects certificate enrollment, the following message is logged:
00:17:25: %CRYPTO-6-CERTREJECT: Certificate enrollment request was rejected by Certificate Authority
This message may indicate that the CA administrator has rejected the enrollment request, that the CA server has already issued a certificate to the router, or that you supplied an incorrect challenge password during enrollment.
The router cannot enroll with a Microsoft CA server.
If you cannot enroll the router with a Microsoft CA server, this may indicate that the server is not configured to support Simple Certificate Enrollment Protocol (SCEP).
Cisco routers use SCEP for certificate enrollment. Microsoft CA servers require you to install an additional component to support SCEP. This component can be installed by running the cepsetup.exe executable, which is available on the Microsoft Web site (www.microsoft.com).
The password you supplied during enrollment is incorrect.
If you are using a Microsoft CA server, and it is configured to require a password during enrollment, you can view the password at the following URL:
http://certificate-server-name-or-IP-address/certsrv/mscep
IKE Negotiation Fails with a Remote VPN Client
When connecting to a Cisco IOS router in a remote access VPN environment, you must be careful to ensure that the Cisco IOS router is configured to support IKE policy and IPSec transform set parameters that are compatible with the client.
In this example, a remote access user running Cisco VPN Client 3.x is attempting to connect to the corporate network via an IPSec tunnel to the Tokyo IOS router, as illustrated in Figure 8-18.
Figure 8-18. Remote Access Client Connects to the Corporate Network
When the client attempts to make a connection, however, it fails.
A Cisco VPN client should negotiate aggressive mode in phase 1, then extended authentication of the initiator (the VPN client) to the responder (Tokyo, in this case) should take place, parameters such as an IP address should be pushed to the client, and quick mode (phase 2) negotiation should be completed.
The network administrator examines the IKE negotiation sequence between the remote access client and Tokyo, using the debug crypto isakmp command. The output is shown in Examples 8-103 to 8-107.
Example 8-103. Aggressive Mode Negotiation with Remote Access Client Fails
Tokyo#debug crypto isakmp Crypto ISAKMP debugging is on Tokyo# *Mar 15 16:13:42.807 GMT: ISAKMP (0:0): received packet from 172.16.7.56 dport 500 sport 500 (N) NEW SA *Mar 15 16:13:42.807 GMT: ISAKMP: Found a peer struct for 172.16.7.56, peer port 500 by CONFIG *Mar 15 16:13:42.811 GMT: ISAKMP: Locking peer struct 0x63BD36FC, IKE refcount 1 for crypto_ikmp_config_initialize_sa *Mar 15 16:13:42.811 GMT: ISAKMP (0:0): (Re)Setting client xauth list and state *Mar 15 16:13:42.811 GMT: ISAKMP: local port 500, remote port 500 *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing SA payload. message ID = 0 *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing ID payload. message ID = 0 *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing vendor id payload *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID seems Unity/DPD but bad major *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID is XAUTH *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing vendor id payload *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID is DPD *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID is NAT-T *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing vendor id payload *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID seems Unity/DPD but bad major *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID is NAT-T *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing vendor id payload *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID seems Unity/DPD but bad major *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing vendor id payload *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID is Unity *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID is NAT-T *Mar 15 16:13:42.811 GMT: ISAKMP (0:1) Authentication by xauth preshared |
In highlighted line 1, phase 1 aggressive mode negotiation begins when a packet is received from the remote access client (172.16.7.56).
Tokyo then begins to process the contents of the packet, starting with the IKE SA, ID, and vendor ID payloads.
The vendor ID payload is used to announce capabilities such as extended authentication (XAUTH), dead peer discovery (DPD), NAT transparency (NAT-T), and support for the Unity protocol.
The IKE SA payload transforms (which correspond to IKE policies) sent by the remote access client are now compared to the policies configured on Tokyo, as shown in Example 8-104.
Example 8-104. SA Payload Transform to Tokyo's ISAKMP Policy Comparison Begins
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): Checking ISAKMP transform 1 against priority 10 policy *Mar 15 16:13:42.811 GMT: ISAKMP: encryption AES-CBC *Mar 15 16:13:42.811 GMT: ISAKMP: hash SHA *Mar 15 16:13:42.811 GMT: ISAKMP: default group 2 *Mar 15 16:13:42.811 GMT: ISAKMP: auth XAUTHInitPreShared *Mar 15 16:13:42.811 GMT: ISAKMP: life type in seconds *Mar 15 16:13:42.811 GMT: ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B *Mar 15 16:13:42.811 GMT: ISAKMP: keylength of 256 *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): Encryption algorithm offered does not match policy! *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 3 *Mar 15 16:13:42.811 GMT: ISAKMP (0:1): Checking ISAKMP transform 2 against priority 10 policy *Mar 15 16:13:42.811 GMT: ISAKMP: encryption AES-CBC *Mar 15 16:13:42.811 GMT: ISAKMP: hash MD5 *Mar 15 16:13:42.811 GMT: ISAKMP: default group 2 *Mar 15 16:13:42.811 GMT: ISAKMP: auth XAUTHInitPreShared *Mar 15 16:13:42.815 GMT: ISAKMP: life type in seconds *Mar 15 16:13:42.815 GMT: ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B *Mar 15 16:13:42.815 GMT: ISAKMP: keylength of 256 *Mar 15 16:13:42.815 GMT: ISAKMP (0:1): Encryption algorithm offered does not match policy! *Mar 15 16:13:42.815 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 3 |
In highlighted line 1 of Example 8-104, the first transform sent by the client is compared to IKE policy 10.
The attributes of the of the transform are then listed, and in highlighted line 2, Tokyo reports that the encryption algorithm (AES) contained within the transform does not match that in policy 10. For this reason, Tokyo rejects the transform in highlighted line 3.
Note also the message Next payload 3 message in highlighted line 3. This indicates that there is another transform contained in the packet sent by the client (see Table 8-1).
Tokyo now begins to compare this next transform to policy 10 (highlighted line 4), and in highlighted line 5 reports once again that the encryption algorithm does not match that in policy 10.
Note the attributes contained within the second transform (shown between highlighted lines 4 and 5) and those of the first transform (shown between highlighted lines 1 and 2). Notice that the hash algorithms are different (MD5 against SHA).
Tokyo continues to process and reject another 11 transforms (not shown for the sake of brevity/your sanity) until it reaches the 13th and 14th transforms, as shown in Example 8-105.
Example 8-105. SA Payload Comparison Ends
*Mar 15 16:13:42.819 GMT: ISAKMP (0:1): Checking ISAKMP transform 13 against priority 10 policy *Mar 15 16:13:42.819 GMT: ISAKMP: encryption DES-CBC *Mar 15 16:13:42.819 GMT: ISAKMP: hash MD5 *Mar 15 16:13:42.819 GMT: ISAKMP: default group 2 *Mar 15 16:13:42.819 GMT: ISAKMP: auth XAUTHInitPreShared *Mar 15 16:13:42.819 GMT: ISAKMP: life type in seconds *Mar 15 16:13:42.819 GMT: ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B *Mar 15 16:13:42.819 GMT: ISAKMP (0:1): Diffie-Hellman group offered does not match policy! *Mar 15 16:13:42.819 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 3 *Mar 15 16:13:42.819 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 3 *Mar 15 16:13:42.823 GMT: ISAKMP (0:1): Checking ISAKMP transform 14 against priority 10 policy *Mar 15 16:13:42.823 GMT: ISAKMP: encryption DES-CBC *Mar 15 16:13:42.823 GMT: ISAKMP: hash MD5 *Mar 15 16:13:42.823 GMT: ISAKMP: default group 2 *Mar 15 16:13:42.823 GMT: ISAKMP: auth pre-share *Mar 15 16:13:42.823 GMT: ISAKMP: life type in seconds *Mar 15 16:13:42.823 GMT: ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B *Mar 15 16:13:42.823 GMT: ISAKMP (0:1): Diffie-Hellman group offered does not match policy! *Mar 15 16:13:42.823 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 0 |
Having rejected 12 previous transforms because their encryption algorithms (AES and 3DES, not shown) do not match the policy, Tokyo now rejects these transforms because the Diffie-Hellman group does not match (highlighted lines 1 to 7). This is significant because it indicates that the encryption and hash algorithms (DES and MD5) specified in these transforms are OK.
Notice also the Diffie-Hellman group contained within the transforms shown in Examples 8-104 and 8-105. It is group 2. This is also the group specified in the transforms that are not shown. Also note the Next payload 0 message in highlighted line 7. This indicates that there are no more payloads (and transforms) contained in the packet (see Table 8-1).
Having failed to match any of the transforms sent by the client to policy 10, Tokyo begins to compare them to the default policy (65535).
Example 8-107 shows the comparison of the transforms to the default policy. Only the first and last (14th) comparisons are shown.
Example 8-106. Tokyo Compares the Client Transforms to the Default Policy
*Mar 15 16:13:42.823 GMT: ISAKMP (0:1): Checking ISAKMP transform 1 against priority 65535 policy *Mar 15 16:13:42.823 GMT: ISAKMP: encryption AES-CBC *Mar 15 16:13:42.823 GMT: ISAKMP: hash SHA *Mar 15 16:13:42.823 GMT: ISAKMP: default group 2 *Mar 15 16:13:42.823 GMT: ISAKMP: auth XAUTHInitPreShared *Mar 15 16:13:42.823 GMT: ISAKMP: life type in seconds *Mar 15 16:13:42.823 GMT: ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B *Mar 15 16:13:42.823 GMT: ISAKMP: keylength of 256 *Mar 15 16:13:42.823 GMT: ISAKMP (0:1): Encryption algorithm offered does not match policy! *Mar 15 16:13:42.823 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 3 ! Output omitted for brevity *Mar 15 16:13:42.831 GMT: ISAKMP (0:1): Checking ISAKMP transform 14 against priority 65535 policy *Mar 15 16:13:42.831 GMT: ISAKMP: encryption DES-CBC *Mar 15 16:13:42.831 GMT: ISAKMP: hash MD5 *Mar 15 16:13:42.831 GMT: ISAKMP: default group 2 *Mar 15 16:13:42.831 GMT: ISAKMP: auth pre-share *Mar 15 16:13:42.831 GMT: ISAKMP: life type in seconds *Mar 15 16:13:42.831 GMT: ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B *Mar 15 16:13:42.831 GMT: ISAKMP (0:1): Hash algorithm offered does not match policy! *Mar 15 16:13:42.831 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 0 *Mar 15 16:13:42.831 GMT: ISAKMP (0:1): no offers accepted! *Mar 15 16:13:42.831 GMT: ISAKMP (0:1): phase 1 SA not acceptable! |
In highlighted lines 1 to 3, Tokyo compares transform one to the default policy and then rejects it because the encryption algorithm (AES) does not match.
Then in highlighted lines 4 to 6, Tokyo compares the 14th and final transform to the default policy and again rejects it—this time because the hash algorithm (MD5) does not match.
Finally, Tokyo reports that no offers (transforms) were accepted and that phase 1 as a whole was not acceptable (highlighted lines 7 and 8).
So phase 1 was not acceptable, and Tokyo now begins to terminate aggressive mode negotiation accordingly as shown in Example 8-107.
Example 8-107. Tokyo Terminates Aggressive Mode Negotiation
*Mar 15 16:13:42.831 GMT: ISAKMP (0:1): incrementing error counter on sa: construct_fail_ag_init *Mar 15 16:13:42.831 GMT: ISAKMP (0:1): Unknown Input: state = IKE_READY, major, minor = IKE_MESG_FROM_PEER, IKE_AM_EXCH *Mar 15 16:13:42.831 GMT: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Aggressive mode failed with peer at 172.16.7.56 *Mar 15 16:13:47.811 GMT: ISAKMP (0:1): received packet from 172.16.7.56 dport 500 sport 500 (R) AG_NO_STATE *Mar 15 16:13:47.815 GMT: ISAKMP (0:1): phase 1 packet is a duplicate of a previous packet. *Mar 15 16:13:47.815 GMT: ISAKMP (0:1): retransmitting due to retransmit phase 1 *Mar 15 16:13:47.815 GMT: ISAKMP (0:1): retransmitting phase 1 AG_NO_STATE... *Mar 15 16:13:48.315 GMT: ISAKMP (0:1): retransmitting phase 1 AG_NO_STATE... *Mar 15 16:13:48.315 GMT: ISAKMP (0:1): incrementing error counter on sa: retransmit phase 1 *Mar 15 16:13:48.315 GMT: ISAKMP (0:1): retransmitting phase 1 AG_NO_STATE *Mar 15 16:13:48.315 GMT: ISAKMP (0:1): sending packet to 172.16.7.56 my_port 500 peer_port 500 (R) AG_NO_STATE Tokyo# |
Tokyo reports that aggressive mode negotiation has failed with the remote access client (highlighted line 1). Then, in highlighted line 2, Tokyo sends a final (Notify) message to the remote client to inform it of phase 1 failure.
The key to finding out the reason for the failure is shown back in Example 8-105. As pointed out, the comparison of transforms 14 and 15 to policy 10 failed because the Diffie-Hellman group did not match. A likely culprit for IKE policy negotiation failure is the Diffie-Hellman group setting in policy 10 on Tokyo.
The IKE (ISAKMP) policy is then examined using the show crypto isakmp policy command, as shown in Example 8-108.
Example 8-108. Examination of the ISAKMP Policies on Tokyo
Tokyo#show crypto isakmp policy Protection suite of priority 10 encryption algorithm: DES - Data Encryption Standard (56 bit keys). hash algorithm: Message Digest 5 authentication method: Pre-Shared Key Diffie-Hellman group: #1 (768 bit) lifetime: 86400 seconds, no volume limit Default protection suite encryption algorithm: DES - Data Encryption Standard (56 bit keys). hash algorithm: Secure Hash Standard authentication method: Rivest-Shamir-Adleman Signature Diffie-Hellman group: #1 (768 bit) lifetime: 86400 seconds, no volume limit Tokyo# |
Highlighted lines 1 and 2 in Example 8-108 show that the Diffie-Hellman group in both policies is 1. Note also the authentication method in policy 10 is preshared keys.
Unfortunately, Diffie-Hellman group 1 with preshared keys is not supported at all by Cisco VPN Client 3.x. In fact, the only group supported with preshared key authentication is group 2.
The next step is to reconfigure the Diffie-Hellman group for policy 10, as shown in Example 8-109.
Example 8-109. Reconfiguration of the Diffie-Hellman Group
Tokyo#conf t Enter configuration commands, one per line. End with CNTL/Z. Tokyo(config)#crypto isakmp policy 10 Tokyo(config-isakmp)#group 2 Tokyo(config-isakmp)#end Tokyo# |
Once the Diffie-Hellman group is reconfigured, the remote access client reconnects, and IKE negotiation completes successfully.
This is verified using the show crypto isakmp sa command, as demonstrated in Example 8-110.
Example 8-110. IKE Negotiation Has Completed Successfully
Tokyo#show crypto isakmp sa
dst src state conn-id slot
172.16.5.1 172.16.7.56 QM_IDLE 2 0
Tokyo#
|
Example 8-110 shows that IKE phase 1 has successfully negotiated, and the quick mode (phase 2) is in an idle state.
In Example 8-111, successful negotiation of IPSec SAs for the remote access client is verified using the show crypto ipsec sa command.
Example 8-111. Successful IPSec SA Negotiation
Tokyo#show crypto ipsec sa interface: Serial4/0 Crypto map tag: mjlnetMap, local addr. 172.16.5.1 local ident (addr/mask/prot/port): (172.16.5.1/255.255.255.255/0/0) remote ident (addr/mask/prot/port): (10.2.2.57/255.255.255.255/0/0) current_peer: 172.16.7.56:500 PERMIT, flags={} #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 172.16.5.1, remote crypto endpt.: 172.16.7.56 path mtu 1500, media mtu 1500 current outbound spi: 93F3666F inbound esp sas: spi: 0x4C20CF91(1277218705) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2000, flow_id: 1, crypto map: mjlnetMap sa timing: remaining key lifetime (k/sec): (4608000/3573) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x93F3666F(2482202223) transform: esp-des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2001, flow_id: 2, crypto map: mjlnetMap sa timing: remaining key lifetime (k/sec): (4608000/3573) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas: Tokyo# |
Highlighted line 1 shows the remote identity. This is the IP address assigned to the remote access client from the IP address pool configured on Tokyo.
In highlighted line 2, you can see the local and remote tunnel endpoints. These are Tokyo (172.16.5.1) and the remote access client (172.16.7.56). Note that the IP address specified here for the client is the address that the client uses on the Internet.
Finally, in highlighted lines 3 and 4, the inbound and outbound ESP SAs negotiated with the client are shown.
NOTE
Note that when configuring the IKE policy and IPSec transform set on a router, you should always verify the parameters that the client supports.
IKE and IPSec parameters supported by Cisco VPN Client 3.x are shown in Tables 6-2 and 6-3 at the following URL: