Troubleshooting IPSEC VPN

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
 encr 3des
 authentication pre-share
 group 2
  crypto isakmp key ciscokey address 200.200.200.1
  !
  crypto ipsec transform-set TRANSFORM esp-3des esp-sha-hmac
  !
  crypto map VPN 10 ipsec-isakmp
 set peer 200.200.200.1
 set transform-set TRANSFORM
 match address 100
  !
  interface FastEthernet0
  !
  interface FastEthernet1
  !
  interface FastEthernet2
  !
  interface FastEthernet3
  !        
  interface FastEthernet4
 ip address 200.200.100.1 255.255.255.0
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
 crypto map VPN
  !
  interface Vlan1
 ip address 10.10.149.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
  !
  ip classless
  ip route 0.0.0.0 0.0.0.0 200.200.100.2
  !
  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.

Phase 1:

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

  200.200.200.1    200.200.100.1    QM_IDLE           1001    0 ACTIVE

  From the output above we can see the public IP addresses 200.200.200.1 and 200.200.100.1 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:

State	Explanation
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.

Phase 2:

To verify Phase 2 operation use the following command:

SiteA#show crypto ipsec sa

interface: FastEthernet4
      Crypto map tag: VPN, local addr 200.200.100.1
   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 200.200.200.1 port 500
       PERMIT, flags={origin_is_acl,}
      #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.: 200.200.100.1, remote crypto endpt.: 200.200.200.1
       path mtu 1500, ip mtu 1500
       current outbound spi: 0x8BF4C2A1(2348073633)
     inbound esp sas:
        spi: 0x812A50F7(2167034103)
  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.