≡ Menu

How to Configure IPSec VPN

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.

Comments on this entry are closed.

Next post:

Previous post:

Copyright © Nish Vamadevan 2002-2017. All Rights Reserved. Terms and Policies.