Helpful commands for troubleshooting IPSec include the show, clear, and debug commands listed below. This appendix contains examples of these commands.
Note The command output below displays an ISAKMP (IKE) security association (SA) table. In the example,
an SA exists between 172.21.30.71 and 172.21.30.70. The peer should have an SA entry in the same state
as this router's output.
dt1-7ka#show cry isakmp sa
dst src state conn-id slot
172.21.30.70 172.21.30.71 QM_IDLE 47 5
2. show cry isakmp policy
Note The command output below shows the policy objects configured. In this case, policies 1, 2, and 4 are
used, in addition to the default. The policies are proposed to the peer in order, with 1 preferable.
dt1-45a#show cry isakmp policy
Protection suite of priority 1
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
Note The configuration below uses the same router as above, but different show commands. The transform
proposals, the settings they will negotiate, and the defaults are all provided.
S3-2611-2#show cry ip transform
Transform proposal Elvis: { ah-sha-hmac }
supported settings = { Tunnel, },
default settings = { Tunnel, },
will negotiate = { Tunnel, },
{ esp-des }
supported settings = { Tunnel, },
default settings = { Tunnel, },
will negotiate = { Tunnel, },
Transform proposal Bubba: { ah-rfc1828 }
supported settings = { Tunnel, },
default settings = { Tunnel, },
will negotiate = { Tunnel, },
{ esp-des esp-md5-hmac }
supported settings = { Tunnel, },
default settings = { Tunnel, },
will negotiate = { Tunnel, },
Transform proposal BarneyDino: { ah-md5-hmac }
supported settings = { Tunnel, },
default settings = { Tunnel, },
will negotiate = { Tunnel, },
show crypto ipsec sa
wan2611#show crypto ipsec sa
interface: Serial0
Crypto map tag: test, local addr. 20.20.20.21
local ident (addr/mask/prot/port): (50.50.50.0/255.255.255.0/0/0)
local crypto endpt.: 20.20.20.21, remote crypto endpt.: 20.20.20.20
path mtu 1500, media mtu 1500
current outbound spi: 6625CD
inbound esp sas:
spi: 0x1926112F(421859631)
transform: esp-des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 11, crypto map: test
sa timing: remaining key lifetime (k/sec): (4607971/3354)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
spi: 0x12050DD2(302321106)
transform: ah-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 9, crypto map: test
sa timing: remaining key lifetime (k/sec): (4607958/3354)
replay detection support: Y
outbound esp sas:
spi: 0x3262313(52830995)
transform: esp-des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 12, crypto map: test
sa timing: remaining key lifetime (k/sec): (4607971/3354)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
spi: 0x6625CD(6694349)
transform: ah-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 10, crypto map: test
sa timing: remaining key lifetime (k/sec): (4607958/3354)
replay detection support: Y
show crypto ipsec session/show crypto ipsec sa
Note The command output below shows the current IPSec security associations of this router, which is
configured for AH SA for both incoming and outgoing traffic.
Note The command output below shows the crypto map command, the ACLs and the transform proposals
applied to this crypto map, the peers, and the key lifetime.
*Mar 21 20:58:34.507: generate hmac context for conn id 4
*Mar 21 20:58:34.519: CRYPTO(epa_release_crypto_conn_entry): released conn 4
lab-isdn1#
clear crypto sa
lab-isdn1#clear crypto sa
lab-isdn1#
*Mar 21 20:58:42.495: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 12.12.12.13, sa_prot= 51,
sa_spi= 0x4F60465(83231845),
sa_trans= ah-sha-hmac , sa_conn_id= 5
*Mar 21 20:58:42.499: CRYPTO(epa_release_crypto_conn_entry): released conn 5
*Mar 21 20:58:42.499: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 12.12.12.12, sa_prot= 51,
sa_spi= 0x6B024AB(112207019),
sa_trans= ah-sha-hmac , sa_conn_id= 6
*Mar 21 20:58:42.503: CRYPTO(epa_release_crypto_conn_entry): released conn 6
*Mar 21 20:58:42.503: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 12.12.12.13, sa_prot= 50,
sa_spi= 0x21240B07(556010247),
*Mar 21 20:58:42.507: CRYPTO(epa_release_crypto_conn_entry): released conn 7
*Mar 21 20:58:42.507: IPSEC(delete_sa): deleting SA,
(sa) sa_dest= 12.12.12.12, sa_prot= 50,
sa_spi= 0x19591660(425268832),
sa_trans= esp-des esp-sha-hmac , sa_conn_id= 8
*Mar 21 20:58:42.511: CRYPTO(epa_release_crypto_conn_entry): released conn 8
lab-isdn1#
Debug Commands
This section provides sample outputs from executing the debug command during a normal IKE/IPSec session between two routers. The routers in the example use a pre-shared key. The source router has the debug cry isakmp and debug cry ipsec commands enabled. The peer has the same two commands, plus the debug ip packet command enabled.
For information on debug scenarios that illustrate configuration problems (for example, a policy mismatch), see "Sample Problem Scenarios."
Configuring on the Source Router
dt3-4kb#ping 192.168.10.66
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.66, timeout is 2 seconds:
Note that the router offers all of the available transforms to the peer.
ISAKMP (134): beginning Main Mode exchange
ISAKMP (134): processing SA payload. message ID = 0
ISAKMP (134): Checking ISAKMP transform 1 against priority 1 policy
ISAK.!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 8/8/8 ms
dt3-4kb#MP: encryption DES-CBC
ISAKMP: hash MD5
ISAKMP: default group 1
ISAKMP: auth pre-share
ISAKMP (134): atts are acceptable. Next payload is 0
ISAKMP (134): SA is doing pre-shared key authentication
ISAKMP (134): processing KE payload. message ID = 0
ISAKMP (134): processing NONCE payload. message ID = 0
ISAKMP (134): SKEYID state generated
ISAKMP (134): processing ID payload. message ID = 0
ISAKMP (134): processing HASH payload. message ID = 0
ISAKMP (134): SA has been authenticated
ISAKMP (134): beginning Quick Mode exchange, M-ID of -1517735742
IPSEC(key_engine): got a queue event...
IPSEC(spi_response): getting spi 383061134 for SA
from 192.168.10.66 to 192.168.10.38 for prot 3
IPSEC(spi_response): getting spi 542967145 for SA
from 192.168.10.66 to 192.168.10.38 for prot 2
IPSEC(spi_response): getting spi 359212595 for SA
from 192.168.10.66 to 192.168.10.38 for prot 3
IPSEC(spi_response): getting spi 366153874 for SA
from 192.168.10.66 to 192.168.10.38 for prot 2
ISAKMP (134): processing SA payload. message ID = -1517735742
ISAKMP (134): Checking IPSec proposal 1
ISAKMP: transform 1, ESP_DES_IV64
ISAKMP: attributes in transform:
ISAKMP: encaps is 1
ISAKMP: SA life type in seconds
ISAKMP: SA life duration (basic) of 190
ISAKMP: SA life type in kilobytes
ISAKMP: SA life duration (VPI) of
0x0 0x46 0x50 0x0
ISAKMP (134): atts are acceptable.
If debug entries appear for ISAKMP even after the IKE has been established, remember that IKE is the entity that negotiates IPSec SAs on behalf of IPSec.
IPSEC(validate_proposal_request): proposal part #1,
The following comments address each section of the output and relate the collected information back to the functioning of IKE defined by the RFCs.
These lines show the entry of the ping command and the message generated to the operator indicating that the operation has started.
R1# ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
The next lines show the SPD entries for the SA that are included in the SA payload as the proposal and associated transform sets. These lines display the SPD's identification of the destination and source, which allows the definition of packet security. A single protocol is configured, resulting in one proposal that contains two transform sets: DES encryption and HAMC-MD5 authentication. These lines define neither a lifetime limit nor a maximum data transmission; instead, the default settings define these values.
Note The maximum data is a default unit of 4 GB. Because the configuration does not define a lifetime value
or an attribute, 4 GB is assumed to be the maximum data possible for the ISA. This value is realized by
setting the 32-bit attribute in the SA transform set to 0x0 0x46 0x50 0x0. In addition, Phase 1 operations
use cookies for IKE SA creation, and the SPI is set to zero. The connection ID is zero, because this
packet is the first generated for the VPN. No keys are defined, because DH has not transpired, and the
algorithms in the proposal have not been accepted.
IPSEC(sa_request):
(key eng. msg.) src = 10.1.1.2, dest = 10.1.1.1,
src_proxy = 10.1.0.0/255.255.0.0/0/0 (type = 4)
dest_proxy = 10.1.0.0/255.255.0.0/0/0 (type = 4),
protocol = ESP, transform = esp-des esp-md5-hmac,
lifedur = 3600s and 4608000kb,
spi = 0 x 0(0), conn_id =0, keysize=0, flags = 0 x 4004
The main mode starts.
ISAKMP (10): beginning Main Mode exchange
ISAKMP (10): sending packet to 10.1.1.1 (I) MM_NO_STATE
ISAKMP (10): received packet from 10.1.1.1 (I) MM_NO_STATE
ISAKMP (10): processing SA payload, message ID = 0
The section below shows the sending of the Main Mode packet (containing the ISAKMP header and SA payload information) to R2. The responder replies with a single proposal previously established in the original proposal from R1. Should several proposals be provided to R2, only one could be selected and returned unchanged.
This section shows that the SA information has been received from R2. You must to verify the proposal's data has not been changed, and that the accepted proposal is valid according to the policy maintained within the SPD. This section's final line shows that the payload is processed and accepted. The "next payload" statement indicates that the return proposal's generic header is at the end of the SA payload data chain.
ISAKMP (10): Checking ISAKMP transform 1 against priority 1 policy
ISAKMP: encryption DES-CBC
ISAKMP: hash SHA
ISAKMP: default group 1
ISAKMP: auth pre-share
ISAKMP (10): atts are acceptable. Next payload is 0
The line below shows the router's understanding of the ISAKMP as a pre-shared key b based on the peer's IP address. On this basis, the router makes an alignment for computation. ISAKMP (10): SA is doing pre-shared key authentication using id type ID_IP_IPV4_ADDR. The lines below detail the exchange of the third and fourth IKE payloads containing the nonces and public DH values. After this information is obtained and verified, the keys can be created.
The size and number of keys are indicated by the proposal payload information agreed upon in the first two messages. The two systems assume that a limited relationship has been formed, based solely on the peer's IP address and associated policies. The grouping's final line indicates that the keys have been generated. Note that the SKEYID is generated by the responder prior to sending its KE and nonce payloads to the initiator. In so doing, the responder is prepared for future exchanges. However, it has committed to the generation of the key prior to the initiator or any solid authentication. Therefore, this order of events could be processed as a "weakness" and possible denial-of-service against the router. Because the initiator can send only a few messages to the responder that could result in the responder's creation of keys, the initiator is free to flood the responder, consuming system resources.
ISAKMP (10): sending packet to 10.1.1.1 (I) MM_SA_SETUP
ISAKMP (10): receiving packet from 10.1.1.1 (I) MM_SA_SETUP
ISAKMP (10): processing KE payload. message ID = 0
ISAKMP (10): processing NONCE payload. message ID = 0
ISAKMP (10): SKEYID state generated
The following lines add one more attribute to the payload chain, taking advantage of the optional vendor ID payload entry.
ISAKMP (10): processing vendor id payload
ISAKMP (10): speaking to another IOS box!
The following section displays the creation of the ID payload to be presented to the responder. The "next-payload" type of 8 signifies that the HASH_I is to follow. The type of 1 states that the ID payload will contain the IP address of the initiator. The authentication process assumes type 1 from payloads 1 and 2. However, by providing the proper ID payload, there is no confusion, especially if NAT is involved. Protocol and port are defined by the IPSec DOI to be included. For ISAKMP, the protocol is UDP (17), and the port is 500.
Note The "length statement," as opposed to the total length statement, can be confusing. The RFC states that
the length represents the payload and the generic header. From the information gathered, it appears that
the router calculates the generic header length rather than assumes the entire payload and header.
ISAKMP (10): ID payload
next-payload : 8
type : 1
protocol : 17
port : 500
length : 8
ISAKMP (10): Total payload length : 12
In the lines below, the last two exchanges (packets 5 and 6) are performed and finalize the ISA. The fact that this information is encrypted is not detailed in the debug data from R1. The HASH included in the payloads serves to authenticate both the message and the information gathered to this point. Because the ID payload is included in the exchange, it is used as part of the HASH. Other information included in the HASH was exchanged previously. A good example is that cookies are included in the HASH which were shared in the original ISAKMP header. Also included in the HASH are the DH public values that were created by the initiator and received by the responder.
Using the HASH exchanged in the last few packets validates all the peer information. Note that if the password is incorrect, the key generation is based on bad information contained in disparate databases. The result is that the final exchange is decrypted into nonsense causing several vague errors to arise.
Preshared key authentication is very popular, especially with remote access solutions, but there are several weaknesses inherent to the process. At this point, IKE Phase I is complete, and Phase II can begin to create SAs for IPSec operations.
ISAKMP (10): sending packet to 10.1.1.1 (I) MM_KEY_EXCH
ISAKMP (10): received packet from 10.1.1.1 (I) MM_KEY_EXCH
ISAKMP (10): processing ID payload. message ID = 0
ISAKMP (10): processing HASH payload. message ID = 0
ISAKMP (10): SA has been authenticated with 10.1.1.1
The section below shows that R2 has followed through with VPN establishment and has initiated Quick Mode. Note "for prot 3." Protocol 3 is the IPSec domain of interpretation (DOI) identification for IPSec ESP. This can become confusing when it is known that the protocol ID for ESP is 50, but the prot 3 designation is strictly the IPSec's DOI for the Phase II quick mode (QM) negotiation. The SA proposal from R2 that includes the transform sets is missing. In the beginning of the original IKE exchange, you see the identification of ESP, the encryption identification, and the authentication algorithm to utilize.
Note It is important to recognize that the SA payload is defined, authenticated (HASHed) and included in the
first QM packet. The creation of the transform set was not part of the R2 debug. All data is encrypted
using the keys derived from Phase 1.
ISAKMP (10): beginning Quick Mode exchange, M-ID of 953616512
IPSEC (key_engine) : got a queue event...
IPSEC (spi_response) : getting spi 413467620 for SA
from 10.1.1.1 to 10.1.1.2 for prot 3
ISAKMP (10): sending packet to 10.1.1.1 (I) QM_IDLE
ISAKMP (10): received packet from 10.1.1.1 (I) QM_IDLE
ISAKMP (10): processing SA payload. message ID = 953616512
ISAKMP (10): Checking IPsec proposal 1
ISAKMP: transform 1, ESP_DES
ISAKMP: attributes in transform:
ISAKMP: encaps is 1
ISAKMP: SA life type in seconds
ISAKMP: SA life duration (basic) of 3600
ISAKMP: SA life type in kilobytes
ISAKMP: SA life duration (VPI) of 0 x 0 0 x 46 0 x 50 0 x 0
ISAKMP: authenticator is HMAC-MD5
ISAKMP (10): atts are acceptable.
In the following section, the QM packets are exchanged and R1 once again validates the proposal from R2 against the SPD. The line "encap 1" specifies that the SA will use IP encapsulation; therefore, it is a tunnel mode ESP SA. Again, the lifetime is in seconds and kilobytes, which should look familiar from Phase 1. Finally, the authentication type to be used for the SA is derived.
ISAKMP (10): processing NONCE payload. message ID = 953616512
ISAKMP (10): processing ID payload. message ID = 953616512
After the proposals are validated against the SPD, the packets' nonce and ID are processed.
ISAKMP (10): Creating IPsec SAs
inbound SA from 10.1.1.1 to 10.1.1.2 (proxy 10.1.0.0 to 10.1.0.0)
has spi 413467620 and conn_id 11 and flags 4
lifetime of 3600 seconds
lifetime of 4608000 kilobytes
outbound SA from 10.1.1.2 to 10.1.1.1 (proxy 10.1.0.0 to 10.1.0.0)
has spi 55772818 and conn_id 12 and flags 4
lifetime of 3600 seconds
lifetime of 4608000 kilobytes
The section above shows the creation of the SAs; the SPD reflects the policies in the log. The SPD and the SAD communicate to ensure that the SAD creates according to policy requirements.
IPSEC (key_engine) : got a queue event...
IPSEC (initialize_sas): ,
(key eng. msg.) dest = 10.1.1.2, src = 10.1.1.1,
dest_proxy = 10.1.0.0/255.255.0.0/0/0 (type = 4),
src_proxy = 10.1.0.0/255.255.0.0/0/0 (type = 4),
protocol = ESP, transform = esp-des esp-md5-hmac
lifedur = 3600s and 4608000kb
spi = 0 x 18A503E4 (413467620), conn_id = 11, keysize = 0, flags = 0 x 4
Success rate is 80 percent (4/5), round-trip min/avg/max = 4/5/8 ms
R1#
protocol = ESP, transform = esp-des esp-md5-hmac,
lifedur = 3600s and 460800kb,
spi = 0 x 3530692 (55772818), conn_id = 12, keysize = 0, flags = 0 x 4
In the above section, the key engine receives an event to initialize an SA. The source and destinations are verified, and the SA proposals containing the necessary transform sets are compiled. These proposals are simply words in a log that reflect the creation of the ISAKMP data to be handed off to the ESP header and associated operations. As the process is completed, and the VPN is established, the results of the original ping command are displayed. The ping used to initiate the VPN is displayed. The time required for the establishment of the VPN exceeds the time taken for the first ICMP echo request. Therefore, ".!!!!," appears, which indicates that the first echo reply was not received.
The VPN created in this environment is established on Ethernet with no other processes running on the router. The routers in the test are establishing a simple VPN over a high-speed connection. Consequently, the establishment may seem very fast, only a 5-ms average round trip that includes a 20 percent loss in packets. The process is slow. In some real-world implementations, only the second ping command showed successful packets; even then the success rate was limited to the final datagrams. Consequently, this example shows that key creation and establishment of a VPN can have significant impact on system resources.
IPSEC (create_sa): sa created,
(sa) sa_dest = 10.1.1.2, sa_prot = 50
sa_spi = 0 x 18A503E4 (413467620),
sa_trans = esp-des esp-md5-hmac, sa_conn_id = 11
IPSEC (create_sa): sa created,
(sa) sa_dest = 10.1.1.1, sa_prot = 50
sa_spi = 0 x 3530692 (55772818),
sa_trans = esp-des esp-md5-hmac, sa_conn_id = 12
ISAKMP (10): sending packet to 10.1.1.1 (I) QM_IDLE
The router now displays the current SA's status. The SPIs relate to the two SAs and can be used to identify and track the activities of the respective SAs. The following is the result of a command that displays the ISAKMP SA status and allows the verification of actions within the SAs. The show crypto isakmp sa command provides a detailed list of security association attributes and statistics. The command output provides not only the IKE SA information, but offers the IPSec SA data, as well, for both protocols. This command is very valuable in troubleshooting and allows the operator to determine the system configuration.
R1#sh crypto isakmp sa
Crypto map tag: VPN-TO-R2, local addr. 10.1.1.2
local ident (addr/mask/prot/port):
(10.1.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port):
(10.1.0.0/255.255.0.0/0/0)
current_peer: 10.1.1.1
PERMIT, flag = {origin_is_acl,}
#pkts encaps: 7, #pkts encrypt: 7, #pkts digest 7
#pkts decaps: 7, #pkts decrypt: 7, #pkts verify 7
#send errors 2, #recv errors 0
local crypto endpt.: 10.1.1.2, remote crypto
endpt.: 10.1.1.1
path mtu 1500, media mtu 1500
current outbound spi: 188913E4
Within the command output, four areas detail the existing inbound and outbound SAs. The report includes sections that identify the two possible security protocols. In this example, however, there are no AH SAs, because only the ESP security protocol was used.
