I have come across an odd scenario on pre-share key based IPSec tunnels…

The question being, when an IPSec tunnel is active (Phase 1 and 2 are UP) and the pre-share key is changed, does this tear down the tunnel?

The tunnel configuration on R4 follows…

!
crypto isakmp policy 1
 encr aes 256
 hash md5
 authentication pre-share
 group 2
crypto isakmp key fnode address 192.168.1.5
!
!
crypto ipsec transform-set FNODE1 esp-3des esp-sha-hmac
!
crypto map FNODE1 1 ipsec-isakmp
 set peer 192.168.1.5
 set transform-set FNODE1
 match address 120
!

!
interface Ethernet0/0
 ip address 192.168.1.4 255.255.255.0
 full-duplex
 crypto map FNODE1
!

access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255
!

The tunnel configuration on R5 follows…

!
crypto isakmp policy 1
 encr aes 256
 hash md5
 authentication pre-share
 group 2
crypto isakmp key fnode address 192.168.1.4
!
!
crypto ipsec transform-set FNODE1 esp-3des esp-sha-hmac
!
crypto map FNODE1 1 ipsec-isakmp
 set peer 192.168.1.4
 set transform-set FNODE1
 match address 120
!

!
interface Ethernet0/0
 ip address 192.168.1.5 255.255.255.0
 full-duplex
 crypto map FNODE1
!

access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.1.0 0.0.0.255

Bringing the tunnel up by pinging the Peer from R4

R4#ping 192.168.1.5 so e0/0

As you can see below, the Tunnel is now UP/UP, and 4 packets have been encrypted / decrypted.

R4#sh cry isa sa
dst             src             state          conn-id slot status
192.168.1.5     192.168.1.4     QM_IDLE              1    0 ACTIVE

R4#
R4#sh cry ip sa

interface: Ethernet0/0
    Crypto map tag: FNODE1, local addr 192.168.1.4

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   current_peer 192.168.1.5 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0

     local crypto endpt.: 192.168.1.4, remote crypto endpt.: 192.168.1.5
     path mtu 1500, ip mtu 1500
     current outbound spi: 0x82E8BCA5(2196290725)

     inbound esp sas:
      spi: 0x267E7582(645821826)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: 1, crypto map: FNODE1
        sa timing: remaining key lifetime (k/sec): (4484045/3526)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x82E8BCA5(2196290725)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: 2, crypto map: FNODE1
        sa timing: remaining key lifetime (k/sec): (4484045/3524)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
R4#

Lets change the Pre-Share Key on R4

R4(config)#no crypto isakmp key fnode address 192.168.1.5
R4(config)#
R4(config)#crypto isakmp key fnode@@@_@ address 192.168.1.5

Now, I have changed the key and pinged the remote peer again… Then checked whether the tunnel has gone down…?

As you can see below, there were 9 packets been encrypted and decrypted and tunnel is still UP/UP!

R4#sh cry isa sa
dst             src             state          conn-id slot status
192.168.1.5     192.168.1.4     QM_IDLE              1    0 ACTIVE

R4#

R4#sh cry ip sa | i pkts
    #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
R4#

Now, we will clear ISAKMP and Crypto MAP…

R4#clear cry isa
R4#clear crypto sa map FNODE1

Now, as we expect, the tunnel is brought down…

R4#sh cry isa sa
dst             src             state          conn-id slot status

R4#

R4#sh cry ipsec sa

interface: Ethernet0/0
    Crypto map tag: FNODE1, local addr 192.168.1.4

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   current_peer 192.168.1.5 port 500
     PERMIT, flags={origin_is_acl,}
    #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 0, #recv errors 0

     local crypto endpt.: 192.168.1.4, remote crypto endpt.: 192.168.1.5
     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:
R4#

As expected, when we sent interesting traffic, the tunnel did not come up due to mis-match of pre-share key… “MM_KEY_EXCH”

R4#sh cry isa sa
dst             src             state          conn-id slot status
192.168.1.5     192.168.1.4     MM_KEY_EXCH          1    0 ACTIVE

R4#

Now, we set the key back to the original one…

R4(config)#no crypto isakmp key fnode@@@_@ address 192.168.1.5
R4(config)#crypto isakmp key fnode address 192.168.1.5

As expected, the tunnel comes back up when we sent interesting traffic…

R4#sh cry ip sa

interface: Ethernet0/0
    Crypto map tag: FNODE1, local addr 192.168.1.4

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   current_peer 192.168.1.5 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 6, #recv errors 0

     local crypto endpt.: 192.168.1.4, remote crypto endpt.: 192.168.1.5
     path mtu 1500, ip mtu 1500
     current outbound spi: 0xE15525F6(3780453878)

     inbound esp sas:
      spi: 0x3D15E740(1024845632)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2002, flow_id: 2, crypto map: FNODE1
        sa timing: remaining key lifetime (k/sec): (4578721/3577)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0xE15525F6(3780453878)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2001, flow_id: 1, crypto map: FNODE1
        sa timing: remaining key lifetime (k/sec): (4578721/3576)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
R4#

The fact of the matter is, whenever there is a change is pre-share key and such, the tunnel MUST be cleared to take effect, otherwise it will _not_ come back up.

In another word, when there is an active tunnel and such modifications are made to the configuration, clearing ISAKMP and Crypto MAP is a must.

I have been going through YouYube and found this great video about IPSec…

www.youtube.com/watch?v=DH1zI8QYi4A