This post discusses the most basic steps needed to troubleshoot a LAN-to-LAN IPSEC tunnel between Cisco Routers.
A Cisco Router with the proper IOS version can make an excellent IPSEC VPN termination device, and can be used to securely connect two distant LANs over an untrusted network, such as the Internet. In our example below, we use two Cisco 800 series broadband routers to create an IPSEC VPN tunnel between two offices over a DSL broadband connection via the Internet.
A sample of the configuration concerning the example above is shown below:
hostname siteA !
crypto isakmp policy 1
crypto isakmp key ciscokey address 184.108.40.206
crypto ipsec transform-set TRANSFORM esp-3des esp-sha-hmac
crypto map VPN 10 ipsec-isakmp
set peer 220.127.116.11
set transform-set TRANSFORM
match address 100
ip address 18.104.22.168 255.255.255.0
ip nat outside
crypto map VPN
ip address 10.10.149.1 255.255.255.0
ip nat inside
ip route 0.0.0.0 0.0.0.0 22.214.171.124
ip nat inside source list 101 interface FastEthernet4 overload
access-list 100 permit ip 10.10.149.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 101 deny ip 10.10.149.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 101 permit ip 10.10.149.0 0.0.0.255 any
When using the IPSEC Key Exchange (IKE) mechanism for setting up the VPN tunnel, there are two Phases in the ISAKMP (Internet Security Association and Key Management Protocol) operation:
- Phase 1: In this phase the two nodes verify their identity and establish an initial secure communication channel for further IKE communication. The parameters negotiated in this Phase include the Encryption algorithm (e.g 3DES), a hash algorithm (MD5 or SHA), an authentication method (e.g pre-shared keys), and a Diffie-Hellman group.
- Phase 2: Using the secure communication channel established in Phase 1, the two nodes in Phase 2 negotiate Security Associations (SA) for IPSEC Transforms (AH for authentication or ESP for Encryption).
Therefore, in order to efficiently troubleshoot the IPSEC VPN operation, we need to check the two phases independently, starting always with Phase 1 to see if it has been established correctly, and then verifying Phase 2 establishment.
The following command shows the status of Phase 1 negotiation:
SiteA#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
126.96.36.199 188.8.131.52 QM_IDLE 1001 0 ACTIVE
From the output above we can see the public IP addresses 184.108.40.206 and 220.127.116.11 used as source and destination between the two Site Routers. The most important field to check here is the ‘state’ field which must be ‘QM_IDLE’ in order for Phase 1 to be correctly established. Other possible states in this field are:
|MM_NO_STATE||The ISAKMP SA has been created, but nothing else has happened yet. It is “larval” at this stage—there is no state.|
|MM_SA_SETUP||The peers have agreed on parameters for the ISAKMP SA.|
|MM_KEY_EXCH||The peers have exchanged Diffie-Hellman public keys and have generated a shared secret. The ISAKMP SA remains unauthenticated.|
|MM_KEY_AUTH||The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to QM_IDLE, and a Quick Mode exchange begins.|
To verify Phase 2 operation use the following command:
SiteA#show crypto ipsec sa
Crypto map tag: VPN, local addr 18.104.22.168
protected vrf: (none)
local ident (addr/mask/prot/port): (10.10.149.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.10.1.0/255.255.255.0/0/0)
current_peer 22.214.171.124 port 500
#pkts encaps: 1843, #pkts encrypt: 1843, #pkts digest: 1843
#pkts decaps: 2618, #pkts decrypt: 2618, #pkts verify: 2618
#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.: 126.96.36.199, remote crypto endpt.: 188.8.131.52
path mtu 1500, ip mtu 1500
current outbound spi: 0x8BF4C2A1(2348073633)
inbound esp sas:
transform: esp-3des esp-sha-hmac ,
The important points to watch in the output above are the pkts encrypt and pkts decrypt. These values show if packets are successfully encrypted and decrypted inside the VPN tunnel. The output above shows that Phase 2 is succesfuly established.
If you see only packets encrypted without any decrypted packets (or vice-versa), this means that the VPN tunnel works only one-way, which is not correct. You can then use the command: debug crypto ipsec to get a more detailed explanation why Phase 2 failed.
Leave a Reply