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.
Leave a Reply