Troubleshooting IPsec on IOS and ASA devices

Blog

Sep 24, 2011 3:46 AM
Sep 24th, 2011

Introduction

Recently there were quite a few blog posts on VPN forums relating to troubleshooting common issues in IPsec VPN.

Ankur & others have posted a few nice articles.

I do find, however, that to troubleshoot core issues of IPsec VPN - be it a mis-configuration or a bug - you need to know how the protocol works.

And even if you do, different devices behave differently and provide different outputs.

What have I been up to

Over the course of last few months I have been trying to make it easy for wannabe troubleshooters to diagnose and enable to correct themselves common issues of IPsec VPN.

To do this however, let's recap what you should know about IKE

High level view of IKE version 1 exchange

As many of you know IKE version 1 has following modes:

- Aggressive mode

- Main mode

Aggressive mode is typically used for EzVPN when using pre-shared key (PSK).

Main mode is the mode we use when establishing Lan-to-Lan/DMVPN/SVTI tunnels or ezvpn with use of certificates.

Note that I refer to messages below, not packets. This is a common misconception, a message might need multiple packets to be sent.

1. Aggressive mode.

Aggressive mode needs 3 messages to establish phase 1 association and additional 3 to establish IPsec SA to be able to pass traffic (called Quick Mode - QM).

2. Main mode.

Main mode exchanges 6 messages to establish phase 1 and again additional 3 messages to finish Quick Mode - same way as in aggressive mode.

The main advantage of main mode is that it is more secure. Aggressive mode will exchange your pre-shared key in a hashed form, but not encryped. That is why to improve security users are required also to provide their username and password.

Result of my work.

The result of my work is a few articles to cover the most common deployments.

The intention is to help troubleshooters map CLI commands to messages in debugging and vice versa, understanding how messages in debugging map to configuration.

The documents will also serve as reference for people who would like to know how successful debugging session looks like.

Based on them you might be able to find where your session breaks.

Hopefully this help of those they will be able to spot problems without involving TAC. ;-)

The documents.

Here are the documents I have written so far:

3. Aggressive mode on ASA:

https://supportforums.cisco.com/docs/DOC-13715

4. Aggressive mode on IOS:

https://supportforums.cisco.com/docs/DOC-17021

5. Main mode on ASA:

https://supportforums.cisco.com/docs/DOC-14044

6. Main mode on IOS:

https://supportforums.cisco.com/docs/DOC-18522

A look to the future.

Not the above mentions only IKE version 1.

Cisco devices already implement IKEv2 which is the future of IPsec.

The new protocol is more robust, compact and also getting wide support across different vendors.

To get you started on IKEv2 some time ago I wrote following blog post:

https://supportforums.cisco.com/community/netpro/security/vpn/blog/2010/12/22/ike-version-2-at-a-glance

Comments? Feedback? Requests?

If you have any comments to the work, please remember it is a work of one person. I do make mistakes, and I will gladly fix them.

You can leave feedback in comments to this blog post or under the documents. It is always welcome.

Would you like to see any other articles written on the topic of VPN, maybe?

Average Rating: 0 (0 ratings)

Comments

Patrick0711 Mon, 11/14/2011 - 18:42

Neither main or aggressive mode exchange a hash of the pre-shared key.  They derive the base session key and the 3 subsequent session keys using a pseudo random function that is composed of the pre-shared key amongst other values (most importantly the DH key values).

The subsequent session key information (SKEYID_e specifically) is used as they keying material in conjunction with the defined encryption algorithm to encrypt the 5th and 6th main mode exchanges as well as all subsequent quick mode exchanges.

Aggressive mode is used for remote-access VPN tunnels because the identity value (which is used to perform a pre-shared key look up in the configuration) must be sent in clear text.  Main mode doesn't need to see the identity value in clear-text because it uses the peer IP that the first ISAKMP message was received from to perform the pre-shared key look up.

aespindola09 Tue, 02/28/2012 - 05:54

Hello, I have problems with a network that add to our Router 800, show ipsec sa send errors to the 172.17.0.0 network which I can not get it to connect, I spend my configuration:

ip nat pool branch 200.89.177.111 200.89.177.111 netmask 255.255.255.248

ip nat inside source route-map nonat pool branch overload

!

access-list 120 remark SDM_ACL Category=20

access-list 120 permit ip 172.30.19.192 0.0.0.63 200.49.83.0 0.0.0.255

access-list 120 permit ip 172.30.19.192 0.0.0.63 172.17.0.0 0.0.255.255

access-list 130 deny   ip 172.30.19.192 0.0.0.63 200.49.83.0 0.0.0.255

access-list 130 deny   ip 172.30.19.192 0.0.0.63 172.17.0.0 0.0.255.255

access-list 130 permit ip 172.30.19.192 0.0.0.63 any

y el show crypto ipsec sa:

SOAPL-VPN#show crypto ipsec sa

interface: FastEthernet4
    Crypto map tag: nolan, local addr 200.89.177.211

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.30.19.192/255.255.255.192/0/0)
   remote ident (addr/mask/prot/port): (172.17.0.0/255.255.0.0/0/0)
   current_peer 200.71.232.2 port 500
     PERMIT, flags={origin_is_acl,ipsec_sa_request_sent}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 391, #recv errors 0

     local crypto endpt.: 200.89.177.211, remote crypto endpt.: 200.71.232.2
     path mtu 1500, ip mtu 1500
     current outbound spi: 0x0(0)

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.30.19.192/255.255.255.192/0/0)
   remote ident (addr/mask/prot/port): (200.49.83.0/255.255.255.0/0/0)
   current_peer 200.71.232.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 15475, #pkts encrypt: 15475, #pkts digest: 15475
    #pkts decaps: 15734, #pkts decrypt: 15734, #pkts verify: 15734
    #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.89.177.211, remote crypto endpt.: 200.71.232.2
     path mtu 1500, ip mtu 1500
     current outbound spi: 0xE21A0585(3793356165)

     inbound esp sas:
      spi: 0xE7E8C6A7(3890792103)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 3, flow_id: C87X_MBRD:3, crypto map: nolan
        sa timing: remaining key lifetime (k/sec): (4386876/86369)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xE21A0585(3793356165)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        conn id: 4, flow_id: C87X_MBRD:4, crypto map: nolan
        sa timing: remaining key lifetime (k/sec): (4386876/86369)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

Hopefully they can help me.

thank you very much Hopefully they can help me.
thank you very much

Alexis

jorn.lukassen Mon, 03/05/2012 - 12:25

Great work, man.

Your articles are of real contribute, especially for a tough subject like this. Keep'em coming !

Actions

Login or Register to take actions

This Blog

Posted September 24, 2011 at 3:46 AM
Stats:
Comments:5 Avg. Rating:0
Views:7812   
Shares:0
Categories: ASA
+

Related Content

Blogs Leaderboard