Previous Section  < Day Day Up >  Next Section

Monitoring and Troubleshooting Site-to-Site IPSec VPNs

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

Monitoring Site-to-Site VPNs

If you want to check the status of the IPSec tunnels, you can start by looking at Phase 1 SA state. You can type show crypto isakmp sa detail, as demonstrated in Example 15-30. If the ISAKMP negotiations are successful, you should see the state as MM_ACTIVE. It also displays the type of the IPSec tunnel and the negotiated Phase 1 policy.

Example 15-30. Output of show crypto isakmp sa detail
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.1

    Type    : L2L             Role    : responder

    Rekey   : no              State   : MM_ACTIVE

    Encrypt : aes-256         Hash    : MD5

    Auth    : preshared       Lifetime: 86400

    Lifetime Remaining: 36536

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

Example 15-31. Output of show crypto ipsec sa
Chicago# show crypto ipsec sa

interface: outside

    Crypto map tag: IPSec_map, local addr: 209.165.200.225



      local ident (addr/mask/prot/port): (192.168.10.0/255.255.255.0/0/0)

      remote ident (addr/mask/prot/port): (192.168.30.0/255.255.255.0/0/0)

      current_peer: 209.165.201.1

      #pkts encaps: 2023, #pkts encrypt: 2023, #pkts digest: 2023

      #pkts decaps: 2112, #pkts decrypt: 2112, #pkts verify: 2112

      #pkts compressed: 0, #pkts decompressed: 0

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

      #send errors: 0, #recv errors: 0



      local crypto endpt.: 209.165.200.225, remote crypto endpt.: 209.165.201.1



      path mtu 1500, ipsec overhead 60, media mtu 1500

      current outbound spi: 0B77BCE7



    inbound esp sas:

      spi: 0x4FEDC46D (1340982381)

         transform: esp-aes-256 esp-sha-hmac

         in use settings ={L2L, Tunnel, }

         slot: 0, conn_id: 1, crypto-map: IPSec_map

         sa timing: remaining key lifetime (kB/sec): (9276/28646)

         IV size: 16 bytes

         replay detection support: Y

    outbound esp sas:

      spi: 0x0B77BCE7 (192396519)

         transform: esp-aes-256 esp-sha-hmac

         in use settings ={L2L, Tunnel, }

         slot: 0, conn_id: 1, crypto-map: IPSec_map

         sa timing: remaining key lifetime (kB/sec): (9276/28644)

         IV size: 16 bytes

         replay detection support: Y

If a hardware encryption card is installed in the security Cisco ASA and you want to look at the counter information to monitor how many packets have gone through the card, you can type the show crypto accelerator statistics command, as demonstrated in Example 15-32.

Example 15-32. Output of show crypto accelerator statistics
Chicago# show crypto accelerator statistics

Crypto Accelerator Status

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

[Capability]

   Supports hardware crypto: True

   Supports modular hardware crypto: False

   Max accelerators: 1

   Max crypto throughput: 100 Mbps

   Max crypto connections: 750

[Global Statistics]

   Number of active accelerators: 1

   Number of non-operational accelerators: 0

   Input packets: 14606

   Input bytes: 3364752

   Output packets: 3648

   Output error packets: 0

   Output bytes: 3828341

[Accelerator 0]

   Status: OK

   Software crypto engine

   Slot: 0

   Active time: 286241 seconds

   Total crypto transforms: 7

[Accelerator 0]

   Status: OK

   Software crypto engine

   Slot: 0

   Active time: 286241 seconds

[Accelerator 1]

   Status: OK

   Encryption hardware device : Cisco ASA-55x0 on-board accelerator (revision 0x0)

                             Boot microcode   : ?CNlite-MC-Boot-Cisco-1.2

                             SSL/IKE microcode: ?CNlite-MC-IPSEC-Admin-3.03

                             IPSec microcode  : ?CNlite-MC-IPSECm-MAIN-2.03

   Slot: 1

   Active time: 286242 seconds

   Total crypto transforms: 186516

   Total dropped packets: 0

   [Input statistics]

      Input packets: 14606

      Input bytes: 3364752

      Input hashed packets: 13060

      Input hashed bytes: 1165772

      Decrypted packets: 14606

      Decrypted bytes: 2655536

   [Output statistics]

      Output packets: 3648

      Output bad packets: 0

      Output bytes: 3828341

      Output hashed packets: 455

      Output hashed bytes: 61880

      Encrypted packets: 3648

      Encrypted bytess: 3747517

Troubleshooting Site-to-Site VPNs

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

debug crypto isakmp [debug level 1-255]

and

debug crypto ipsec [debug level 1-255]

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

Refer to Figure 15-1 for a site-to-site tunnel between the ASA in Chicago and London. To enforce learning, the ISAKMP and IPSec negotiations are discussed on the security Cisco ASA in Chicago. The following debug commands are enabled on the security Cisco ASA.

debug crypto isakmp 127

and

debug crypto ipsec 127

As mentioned in Chapter 1, the tunnel negotiations begin by exchanging the ISAKMP proposals. If the proposal is acceptable, the ASA displays the IKE SA proposal transform acceptable message, as shown in Example 15-33.

Example 15-33. Debugs to Show ISAKMP Proposal Is Acceptable
[IKEv1 DEBUG], IP = 209.165.201.1, processing SA payload

[IKEv1 DEBUG], IP = 209.165.201.1, Oakley proposal is acceptable

.....

[IKEv1 DEBUG], IP = 209.165.201.1, IKE SA Proposal # 1, Transform # 1 acceptable

  Matches global IKE entry # 5

Note

The VPN debugs messages on the security Cisco ASA are very similar to the log messages generated on the VPN 3000 Series Concentrators.


During the ISAKMP SA negotiations, the security Cisco ASA matches the IP address of the VPN peer with the tunnel group. If it finds a match, it displays a "Connection landed on tunnel group" message, as shown in Example 15-34, and continues with the rest of the negotiations (shown as ...). The Cisco ASA displays a "Phase 1 completed" message when the ISAKMP SA is successfully negotiated.

Example 15-34. Debugs to Show Phase 1 Negotiations Are Completed
[IKEv1]: IP = 209.165.201.1, Connection landed on tunnel_group 209.165.201.1

...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, PHASE 1 COMPLETED

After completing Phase 1 negotiations, the security Cisco ASA maps the remote VPN peer to a static crypto map sequence number and checks the IPSec Phase 2 proposal sent by the remote VPN peers. If the received proxy identities and the IPSec Phase 2 proposals match on the security Cisco ASA, it displays an "IPSec SA proposal transform acceptable" message, as demonstrated in Example 15-35.

Example 15-35. Debugs to Show Proxy Identities and Phase 2 Proposals Are Accepted
[IKEv1 DECODE]: ID_IPV4_ADDR_SUBNET ID received--192.168.30.0--255.255.255.0

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Received remote IP Proxy Subnet

data in ID Payload:   Address  192.168.30.0, Mask 255.255.255.0, Protocol 0, Port 0

[IKEv1 DEBUG]: Group = 209.165.201.1, IP = 209.165.201.1, Processing ID

[IKEv1 DECODE]: ID_IPV4_ADDR_SUBNET ID received--192.168.10.0--255.255.255.0

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Received local IP Proxy Subnet

data in ID Payload:   Address  192.168.10.0, Mask 255.255.255.0, Protocol 0, Port 0

...

 [IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Static Crypto Map check,

checking map = IPSec_map, seq = 10...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Static Crypto Map check, map

IPSec_map, seq = 10 is a successful match

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, IKE Remote Peer configured for

SA: IPSec_map

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, processing IPSEC SA

[IKEv1 DEBUG]: Group = 209.165.201.1, IP = 209.165.201.1, IPSec SA Proposal # 1,

Transform # 1 acceptable Matches global IPSec SA entry # 10

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

Example 15-36. Debugs Showing IPSec SAs Are Activated
[IKEv1 DEBUG]: Group = 209.165.201.1, IP = 209.165.201.1, loading all IPSEC SAs

...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Security negotiation complete

  for LAN-to-LAN Group (209.165.201.1) Responder, Inbound SPI = 0xf798f8e5,

  Outbound SPI = 0x56029210

The following four scenarios discuss how to troubleshoot the common issues related to IPSec tunnels. The debug messages are shown if debug crypto isakmp 127 is enabled on the security Cisco ASA.

ISAKMP Proposal Unacceptable

In this scenario, if the ISAKMP proposals are mismatched between the two VPN devices, the Cisco ASA Cisco ASA displays an "All SA proposals found unacceptable" message after processing the first main mode packet, as shown in Example 15-37.

Example 15-37. Debugs to Show Mismatched ISAKMP Policies
[IKEv1 DEBUG]: IP = 209.165.201.1,, processing SA payload

[IKEv1]: IP = 209.165.201.1, IKE DECODE SENDING Message (msgid=0) with payloads :

  HDR + NOTIFY (11) + NONE (0) total length : 96

[IKEv1 DEBUG]: IP = 209.165.201.1, All SA proposals found unacceptable

Mismatched Preshared keys

If the preshared key is mismatched between the VPN devices, the Cisco ASA Cisco ASA displays a "Error, had problems decrypting packet, probably due to mismatched pre-shared key" message after processing the fourth main mode packet. This is shown in Example 15-38.

Example 15-38. Debugs to Show Mismatched Preshared Keys
[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1Received encrypted Oakley Main

  Mode packet with invalid payloads, MessID = 0

[IKEv1]: IP = 209.165.201.1, IKE DECODE SENDING Message (msgid=0) with payloads :

  HDR + NOTIFY (11) + NONE (0) total length : 104

IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, ERROR, had problems decrypting

  packet, probably due to mismatched pre-shared key.  Aborting

Incompatible IPSec Transform Set

The security Cisco ASA displays an "All IPSec SA proposals found unacceptable" if the IPSec transform set is mismatched between the VPN devices. In this case, the Phase 1 SA gets established and the VPN devices fail to negotiate the IPSec SA. The Cisco ASA checks the validity of the crypto map before rejecting the IPSec SA, as shown in Example 15-39.

Example 15-39. Debugs When Incompatible IPSec Transform Set Is used
[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Static Crypto Map check,

  checking map = IPSec_map, seq = 10...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Static Crypto Map check, map

  IPSec_map, seq = 10 is a successful match

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, IKE Remote Peer configured for

  SA: IPSec_map

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, processing IPSEC SA

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, All IPSec SA proposals found

  unacceptable!

Mismatched Proxy Identities

If the encryption ACL on the security Cisco ASA does not match the encryption ACL offered by the other end of the VPN tunnel, the Cisco ASA rejects the IPSec SA and displays a "Crypto Map Policy not found" error with the associated local and remote subnets that the remote VPN device offered. In Example 15-40, the VPN peer 209.165.201.1 wants to negotiate IPSec SAs between 192.168.20.0 and 192.168.30.0, which the security Cisco ASA rejects because the received identities do not match the configured crypto ACL.

Example 15-40. Debugs to Show Mismatched Proxy Identities
[IKEv1 DECODE]: ID_IPV4_ADDR_SUBNET ID received--192.168.30.0--255.255.255.0

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Received remote IP Proxy Subnet

  data in ID Payload:  Address 192.168.30.0,  Mask 255.255.255.0, Protocol 0, Port 0

[IKEv1 DEBUG]: Group = 209.165.201.1, IP = 209.165.201.1, Processing ID

[IKEv1 DECODE]: ID_IPV4_ADDR_SUBNET ID received--192.168.20.0--255.255.255.0

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Received local IP Proxy Subnet

  data in ID Payload:  Address 192.168.20.0,  Mask 255.255.255.0, Protocol 0, Port 0

...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Static Crypto Map check,

  checking map = IPSec_map, seq = 10...

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Static Crypto Map check, map =

  IPSec_map, seq = 10, ACL does not match proxy IDs src:192.168.30.0

  dst:192.168.20.0

[IKEv1]: Group = 209.165.201.1, IP = 209.165.201.1, Tunnel rejected: Crypto Map

  Policy not found for Src:192.168.30.0, Dst: 192.168.20.0!

    Previous Section  < Day Day Up >  Next Section
    Osb плита киев. Читаем.