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 127and
debug crypto ipsec 127As 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!
Summary
Everyday, more and more organizations are deploying IPSec site-to-site tunnels to cut costs on traditional WAN links. It is a responsibility of the security professional to design and implement an IPSec solution that will fit the needs of an organization. If the other end of the IPSec VPN tunnel is managed by a different security professional, make sure that you consult with them before configuring the ISAKMP and IPSec attributes in the ASA. This chapter discussed the configuration guide on how to implement the site-to-site tunnels and discussed the two deployment scenarios. If you implement the solution, and the IPSec tunnel is not working as expected, use the appropriate show commands and monitor the status of the SAs. You can also turn on the ISAKMP and IPSec debugs to help narrow down the issue.
