Monitoring and Troubleshooting Cisco Remote Access VPN

Cisco ASA comes with many show commands to check the health and status of the IPSec tunnels. For troubleshooting purposes, there is a rich set of debug commands to isolate the IPSec-related issues.

Monitoring Cisco Remote Access IPSec VPNs

If you want to see if the IPSec tunnels are working and passing traffic, you can start by looking at the status of Phase 1 SA. Type show crypto isakmp sa detail, as demonstrated in Example 16-50. If the ISAKMP negotiations are successful, you should see the state as AM_ACTIVE.

Example 16-50. show crypto isakmp sa detail Command Output

Chicago# show crypto isakmp sa detail

 Active SA: 1

 Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)

Total IKE SA: 1



1 IKE Peer: 209.165.201.10

 Type : user Role : responder

 Rekey : no State : AM_ACTIVE

 Encrypt : 3des Hash : MD5

 Auth : preshared Lifetime: 86400

 Lifetime Remaining: 86331

You can also check the status of the IPSec SA by using the show crypto ipsec sa command, as shown in Example 16-51. This command displays the negotiated proxy identities along with the actual number of packets encrypted and decrypted by the IPSec engine.

Example 16-51. Output of show crypto ipsec sa Command

Chicago# show crypto ipsec sa

interface: outside

 Crypto map tag: outside_dyn_map, local addr: 209.165.200.225

 local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

 remote ident (addr/mask/prot/port): (192.168.50.60/255.255.255.255/0/0)

 current_peer: 209.165.201.10

 dynamic allocated peer ip: 192.168.50.60



 #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10

 #pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10

 #pkts compressed: 0, #pkts decompressed: 0

 #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0

 #send errors: 0, #recv errors: 0

You can check the status of a hardware encryption card with the show crypto accelerator statistics command. In Example 16-52, the important output from this command is shown, which displays the counter information, such as the number of packets going through the encryption card.

Example 16-52. show crypto accelerator statistics Command Output

Chicago# show crypto accelerator statistics

Crypto Accelerator Status

-------------------------

[Capacity]

 Supports hardware crypto: True

 Supports modular hardware crypto: False

 Max accelerators: 1

 Max crypto throughput: 200 Mbps

 Max crypto connections: 750

[Global Statistics]

 Number of active accelerators: 1

 Number of non-operational accelerators: 0

 Input packets: 18

 Input bytes: 5424

 Output packets: 223

 Output error packets: 0

 Output bytes: 172405

[Accelerator 0]

 Status: Active

! Output omitted for brevity.

Cisco ASA can display global IKE and IPSec counter information, which is helpful in isolating VPN connection problems. Information such as the number of total requests, the number of total SAs created, and the number of failed requests is useful to determine the failure rate for IKE and IPSec SAs in the security appliance. As shown in Example 16-53, you can view this information by using the show crypto protocol statistics ikev1 and show crypto protocol statistics ipsec command.

Example 16-53. Output of show crypto protocol statistics ikev1 Command

Chicago# show crypto protocol statistics ikev1

[IKEv1 statistics]

 Encrypt packet requests: 23

 Encapsulate packet requests: 23

 Decrypt packet requests: 23

 Decapsulate packet requests: 23

 HMAC calculation requests: 63

 SA creation requests: 3

 SA rekey requests: 0

 SA deletion requests: 1

 Next phase key allocation requests: 4

 Random number generation requests: 0

 Failed requests: 1

Chicago# show crypto protocol statistics ipsec

[IPsec statistics]

 Encrypt packet requests: 0

 Encapsulate packet requests: 0

 Decrypt packet requests: 0

 Decapsulate packet requests: 0

 HMAC calculation requests: 0

 SA creation requests: 4

 SA rekey requests: 0

 SA deletion requests: 2

 Next phase key allocation requests: 0

 Random number generation requests: 0

 Failed requests: 1

 

Troubleshooting Cisco IPSec VPN Clients

If the IPSec tunnel is not working for some reason, make sure that you have the proper debug turned on. The following are the two most important debugs to look at:

• debug crypto isakmp [debug level 1-255]
• debug crypto ipsec [debug level 1-255]

By default, the debug level is set to 1. You can increase the severity level up to 255 to get detailed logs. However, in most cases, setting this to 127 gives enough information to determine the root cause of an issue.

Refer to Figure 16-13 and look at the tunnel negotiation between the Cisco ASA and the VPN client. To enforce learning, the following debugs have been enabled:

• debug crypto isakmp 127
• debug crypto ipsec 127

As mentioned in Chapter 1, "Introduction to Network Security," the tunnel negotiations begin by exchanging the ISAKMP proposals. The security appliance shows the tunnel group, ciscovpn in this case, that the VPN client is trying to connect to. If the proposal is acceptable, the Cisco ASA displays a message indicating that the IKE SA proposal is acceptable, as shown in Example 16-54.

Example 16-54. debug Output to Show ISAKMP Proposal Is Acceptable

Chicago# debug crypto isakmp 127

Chicago# debug crypto ipsec 127

[IKEv1 DEBUG]: Group = , IP = 209.165.201.10, processing SA payload

[IKEv1 DEBUG]: Group = , IP = 209.165.201.10, processing ke payload

[IKEv1 DEBUG]: Group = , IP = 209.165.201.10, processing VID payload,



[IKEv1]: IP = 209.165.201.10, Connection landed on tunnel_group ciscovpn

[IKEv1 DEBUG]: Group = ciscovpn, IP = 209.165.201.10, processing IKE SA

[IKEv1 DEBUG]: Group = ciscovpn, IP = 209.165.201.10, IKE SA Proposal # 1, Transform

 # 10 acceptable Matches global IKE entry # 1,

If the proposal is acceptable, the VPN devices try to discover if they are NAT-T capable and if there is an address-translation device between them. If NAT-T is not negotiated or a NAT/PAT device is not detected, they display the Remote end is NOT behind a NAT device. This end is NOT behind a NAT device message, as shown in Example 16-55.

Example 16-55. debug Output to Show NAT-T Discovery Process

[IKEv1 DEBUG]: Group = ciscovpn, IP = 209.165.201.10, processing NAT-Discovery

payload

[IKEv1 DEBUG]: Group = ciscovpn, IP = 209.165.201.10, computing NAT Discovery hash

[IKEv1 DEBUG]: Group = ciscovpn, IP = 209.165.201.10, processing NAT-Discovery

 payload

[IKEv1]: Group = ciscovpn, IP = 209.165.201.10, Automatic NAT Detection Status:

 Remote end is NOT behind a NAT device. This end is NOT behind a NAT device 

After NAT-T negotiations, Cisco ASA prompts the user to specify user credentials. Upon successful user authentication, the security appliance displays a message indicating that the user (ciscouser in this example) is authenticated, as shown in Example 16-56.

Example 16-56. debug Output to Show User Is Authenticated

[IKEv1]: Group = ciscovpn, Username = ciscouser, IP = 209.165.201.10, User

 (ciscouser) authenticated.,



[IKEv1 DEBUG]: Group = ciscovpn, Username = ciscouser, IP = 209.165.201.10,

 constructing blank hash

[IKEv1 DEBUG]: Group = ciscovpn, Username = ciscouser, IP = 209.165.201.10,

 constructing qm hash

The client requests mode-config attributes by sending a list of client-supported attributes, as shown in Example 16-57. Cisco ASA replies back with all of its supported attributes and the appropriate information.

Example 16-57. debug Output to Show Mode-Config Requests

[IKEv1 DEBUG]Processing cfg Request attributes,

[IKEv1 DEBUG]MODE_CFG: Received request for IPV4 address!,

[IKEv1 DEBUG]MODE_CFG: Received request for IPV4 net mask!,

[IKEv1 DEBUG]MODE_CFG: Received request for DNS server address!,

[IKEv1 DEBUG]MODE_CFG: Received request for WINS server address!,

After pushing down the attributes, Cisco ASA displays the "PHASE 1 COMPLETED" message indicating that the ISAKMP SA is successfully negotiated, as demonstrated in Example 16-58.

Example 16-58. debug Output to Show Phase 1 Negotiations Are Completed

[IKEv1]: Group = ciscovpn, Username = ciscouser, IP = 209.165.201.10PHASE 1

 COMPLETED,



[IKEv1 DEBUG]: Group = ciscovpn, Username = ciscouser, IP = 209.165.201.10

 Processing ID,

[IKEv1 DECODE]ID_IPV4_ADDR ID received 192.168.50.60,

[IKEv1]: Group = ciscovpn, Username = ciscouser, IP = 209.165.201.10 Received remote

 Proxy Host data in ID Payload: Address 192.168.50.60, Protocol 0, Port 0,

After completing Phase 1 negotiations, the VPN peers try to negotiate Phase 2 SA by exchanging the proxy identities and the IPSec Phase 2 proposal. If they are acceptable, Cisco ASA displays a message indicating that the IPSec SA proposal is acceptable, as shown in Example 16-59.

Example 16-59. debug Output to Show Proxy Identities and Phase 2 Proposal Are Accepted

[IKEv1 DEBUG]: Group = ciscovpn, Username = ciscouser, IP = 209.165.201.10, IPSec

 SA Proposal # 12, Transform # 1 acceptable Matches global IPSec SA entry # 10,

[IKEv1 DEBUG]: Group = ciscovpn, Username = ciscouser, IP = 209.165.201.10 ,

 Transmitting Proxy Id:

 Remote host: 192.168.50.60 Protocol 0 Port 0

 Local subnet: 0.0.0.0 mask 0.0.0.0 Protocol 0 Port 0

After accepting the transform set values, both VPN devices agree on the inbound and outbound IPSec SAs, as shown in Example 16-60. Once the IPSec SAs have been created, both VPN devices should be able to pass traffic bidirectionally across the tunnel.

Example 16-60. debug Output to Show IPSec SAs Are Activated

IKEv1 DEBUG]: Group = ciscovpn, Username = ciscouser, IP = 209.165.201.10 , loading

 all IPSEC SAs

[IKEv1]: Group = ciscovpn, Username = ciscouser, IP = 209.165.201.10 Security

 negotiation complete for User (jazib) Responder, Inbound SPI = 0x00c6bc19,

 Outbound SPI = 0xa472f8c1,

[IKEv1]: Group = ciscovpn, Username = ciscouser, IP = 209.165.201.10 Adding static

 route for client address: 192.168.50.60 ,

[IKEv1]: Group = ciscovpn, Username = ciscouser, IP = 209.165.201.10 , PHASE 2

 COMPLETED (msgid=8732f056)