Skip navigation
Cisco Learning Home > Certifications > Security (CCNA Security) > Discussions

_Communities

This Question is Answered
15163 Views 6 Replies Latest reply: Oct 8, 2010 10:54 PM by eternalrain RSS

Currently Being Moderated

show crypto isakmp sa problem

Oct 4, 2010 3:14 AM

eternalrain 104 posts since
Jul 6, 2010

hi all

 

i have some question.

first question

is'it i need to apply crypto map in tunnel interface and physical interface that the packet exist?

2nd question

is'it i need to configure static route to force private network traffic go through the tunnel?

3rd question

after i show crypto isakmp sa,my result is in QM_IDLE but later it will disappear.however i issues ping remote host -t but it disappear for long time.how come like that?suppose i issues ping remote host -t,it will appear QM_IDLE or wat when exchange the isakmp key.need some expert help.thanks

 

regards,

eternal

  • Keith Barker - CCIE RS/Security, CISSP 5,351 posts since
    Jul 3, 2009
    Currently Being Moderated
    1. Oct 4, 2010 12:14 PM (in response to eternalrain)
    Re: show crypto isakmp sa problem

    i have some question.

    first question

    is'it i need to apply crypto map in tunnel interface and physical interface that the packet exist?

    2nd question

    is'it i need to configure static route to force private network traffic go through the tunnel?

    3rd question

    after i show crypto isakmp sa,my result is in QM_IDLE but later it will disappear.however i issues ping remote host -t but it disappear for long time.how come like that?suppose i issues ping remote host -t,it will appear QM_IDLE or wat when exchange the isakmp key.need some expert help.thanks

     

    regards,

    eternal

     

     

    Now days, if using a crypto map, you only need it on the physical interface, not the tunnel interface.

     

    If traffic doesn't go through the interface with the crypto map, it won't trigger the encryption.   So yes, there needs to be some type of route, that sends the traffic through the GRE tunnel.   This could be dynamic or static routing.

     

    If the IKE phase 1 is successful, and then IKE phase 2 is as well, the IKE phase 1 isn't needed for the encryption of the traffic.   The default lifetime for an IKE phase 1 tunnel is 1 day.  Unless the peers agreed to a shorter time, or some other factor is cutting that lifetime short, it should continue for the duration of the lifetime.

     

    Best wishes,

     

    Keith

  • Keith Barker - CCIE RS/Security, CISSP 5,351 posts since
    Jul 3, 2009
    Currently Being Moderated
    3. Oct 5, 2010 3:13 AM (in response to eternalrain)
    Re: show crypto isakmp sa problem

     

     

    hi keith

     

    thanks your replies.i know what happen in my show crypto isakmp sa because i set lifetime 5000 in crypto isakmp policy 1 so that's why the QM_IDLE only available 5000 seconds.but i curious that why it cannot start exchange key(QM_IDLE) after lifetime 5000 seconds if the traffic go through the tunnel again?i read from cisco website it said that If no traffic has passed through the tunnel during  the entire life of the security association, a new security association  is not negotiated when the lifetime expires. Instead, a new security  association will be negotiated only when IPSec sees another packet that  should be protected.

     

    one more question


    can you tell me what difference between these two?thanks

     

    1.crypto isakmp policy 1

       lifetime 5000

     

    2.crypto map mymap 10 ipsec-isakmp

       set security-association lifetime seconds 5000

     

    regards,

    eternal


     

    Hello eternal -

     

    Great questions !

     

    Part of this puzzle is that we are dealing with 2 separate tunnels.  One for IKE phase 1, and a second for IKE phase 2.

     

    IKE phase 1 is built as a management tunnel between the 2 peers.  This IKE phase 1 tunnel lifetime is controlled by the parameter in the "crypto isakmp policy x" and the lower value of the two peers is used for this life time.   When this tunnel is built, it is used by the peers for negotiating the next tunnel (the IKE phase 2 tunnel, which is coming next).    If the lifetime for the IKE phase 1 tunnel is 90 seconds, and within that 90 seconds the two peers build the IKE phase 2 tunnel (which has its own lifetime too, controlled by the "set security-association lifetime" command in the crypto map), then the IKE phase 1 tunnel may not be needed any more, if the IKE phase 2 tunnel lifetime is an hour, and that 2nd tunnel is still fine.   In this case, the original IKE phase 1 tunnel would time out after 90 seconds, and the IKE phase 2 SA (tunnel) would go on strong for the duration of its lifetime.

     

    If, after an hour, the IKE phase 2 tunnel expires, and there is more traffic that needs to be encrypted, a new IKE phase 1 tunnel will be built, and used to negotiate a new IPSec SA (phase 2 tunnel), and the process would repeat.

     

    Hope that helps.

     

    One of the best ways to see this is to set a very short lifetime for the IKE phase 1, say 90 seconds, and use a combination of the following commands:

     

    debug crypto isakmp

    show crypto isakmp sa

    show crypto isakmp sa detail

    show crypto ipsec sa

    show crypto ipsec sa | inc pkts|lifetime

    clear crypto sa

     

    A full example is below.   I encourage you to lab this up and verify the same results.   It is one of the best ways to learn.

     

     

     

    R3#show crypto isakmp policy

     

    Global IKE policy
    Protection suite of priority 1
            encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
            hash algorithm:         Secure Hash Standard
            authentication method:  Pre-Shared Key
            Diffie-Hellman group:   #1 (768 bit)
            lifetime:               90 seconds, no volume limit


    R3#show crypto map
    Crypto Map "MYMAP" 10 ipsec-isakmp
            Peer = 10.12.0.1
            Extended IP access list 100
                access-list 100 permit ip host 3.3.3.3 host 1.1.1.1
            Current peer: 10.12.0.1
            Security association lifetime: 4608000 kilobytes/3600 seconds
            PFS (Y/N): N
            Transform sets={
                    MYSET,
            }
            Interfaces using crypto map MYMAP:
                    Serial0/1



    R3#show crypto isakmp sa
    IPv4 Crypto ISAKMP SA
    dst             src             state          conn-id slot status


    IPv6 Crypto ISAKMP SA

     

    R3#


    R3#show crypto ipsec sa | inc pkts|lifetime
        #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


    R3#ping 1.1.1.1 so lo

     

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
    Packet sent with a source address of 3.3.3.3
    .!!!!
    Success rate is 80 percent (4/5), round-trip min/avg/max = 8/11/16 ms
    R3#
    R3#show cryp
    R3#show crypto is
    R3#show crypto isakmp sa
    IPv4 Crypto ISAKMP SA
    dst             src             state          conn-id slot status
    10.12.0.1       10.23.0.3       QM_IDLE           1002    0 ACTIVE

     

    IPv6 Crypto ISAKMP SA

     

    R3#show crypto isakmp sa d
    R3#show crypto isakmp sa detail
    Codes: C - IKE configuration mode, D - Dead Peer Detection
           K - Keepalives, N - NAT-traversal
           X - IKE Extended Authentication
           psk - Preshared key, rsig - RSA signature
           renc - RSA encryption
    IPv4 Crypto ISAKMP SA

     

    C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.

     

    1002  10.23.0.3       10.12.0.1                ACTIVE des  sha  psk  1  00:01:12    
           Engine-id:Conn-id =  SW:2

     

    IPv6 Crypto ISAKMP SA

     

    R3#


    ! 2 minutes go by


    R3#show crypto isakmp sa detail
    Codes: C - IKE configuration mode, D - Dead Peer Detection
           K - Keepalives, N - NAT-traversal
           X - IKE Extended Authentication
           psk - Preshared key, rsig - RSA signature
           renc - RSA encryption
    IPv4 Crypto ISAKMP SA

     

    C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.

     

    1002  10.23.0.3       10.12.0.1                ACTIVE des  sha  psk  1  0           
           Engine-id:Conn-id =  ???
    (deleted)

     

    IPv6 Crypto ISAKMP SA

     

    R3#


    R3#ping 1.1.1.1 so lo 0        


    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
    Packet sent with a source address of 3.3.3.3
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 8/15/20 ms
    R3#show crypto ipsec sa | inc pkts|lifetime
        #pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9
        #pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9
        #pkts compressed: 0, #pkts decompressed: 0
        #pkts not compressed: 0, #pkts compr. failed: 0
        #pkts not decompressed: 0, #pkts decompress failed: 0
            sa timing: remaining key lifetime (k/sec): (4590749/3458)
            sa timing: remaining key lifetime (k/sec): (4590749/3458)
    R3#


    R3#show crypto isakmp sa detail           
    Codes: C - IKE configuration mode, D - Dead Peer Detection
           K - Keepalives, N - NAT-traversal
           X - IKE Extended Authentication
           psk - Preshared key, rsig - RSA signature
           renc - RSA encryption
    IPv4 Crypto ISAKMP SA

     

    C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.

     

    IPv6 Crypto ISAKMP SA

     

    R3#

     

    Best wishes,

     

    Keith

  • Keith Barker - CCIE RS/Security, CISSP 5,351 posts since
    Jul 3, 2009
    Currently Being Moderated
    5. Oct 8, 2010 8:55 AM (in response to eternalrain)
    Re: show crypto isakmp sa problem
    In conclusion after IKE phase 1 timeout,there is no QM_IDLE exist in show crypto isakmp sa.If we set IKE phase 1 in 90 seconds,after 90 seconds it will proceed to IKE phase 2 so in this period there is no QM_IDLE exist in show crypto isakmp sa right.so if IKE phase 2 timeout,IKE phase 1 will renegotiate with remote peer again.so in this period,QM_IDLE exist in show crypto isakmp sa.show crypto isakmp sa is for IKE phase 1 not for IKE phase 2 right?if my conclusion is mistake pls correct me thanks.you really help me a lot in ipsec


    anyway,ur configuration is IPsec LAN to LAN tunnel but mine one is GRE tunnel over IPsec so is'it there are same?

     

    regards,

    eternal

     

    If the IKE phase 1 tunnel is 90 seconds, and the IKE phase 1 tunnel times out, and is not needed, the old IKE phase1 SA is deleted, and NO new IKE phase 1 tunnel is automatically generated (if there is no immediate need for it), and the show commands related specifically to IKE phase 1, such as show crypto isakmp sa detail, will show no IKE phase 1 tunnel.

     

    At the same time, if the IKE phase 2 tunnel, and its SAs are fine, the show commands for the IKE phase 2 SAs will show the tunnel details for IKE phase 2, such as show crypto ipsec sa.

     

    Best wishes,

     

    Keith

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)