ISAKMP policy selection process

[Haris Hilmi Abdul Rahim]

Hi all, 

I have a question regarding how ISAKMP policy is chosen in a router. Router 1 and 3 are connected via IPSec VPN. Below are their ISAKMP policies:

R1#sh run | sec policy
crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 2
crypto isakmp policy 20
 encr 3des
 authentication pre-share
 group 2

==========================

R3#sh run | sec policy
crypto isakmp policy 1
 encr 3des
 authentication pre-share
crypto isakmp policy 10
 encr 3des
 authentication pre-share
 group 2
crypto isakmp policy 20
 encr 3des
 authentication pre-share
 group 2
crypto isakmp policy 30
 encr 3des
 authentication pre-share
 group 2
crypto isakmp policy 40
 encr aes 256
 authentication pre-share
 group 2
 lifetime 1800
crypto isakmp policy 50
 encr aes 256
 authentication pre-share
 group 2

I do not have any problem with phase 2. However, on phase 1 AES/SHA is chosen - but with lifetime of 1800.

R3#sh crypto isa sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       T - cTCP encapsulation, 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.

1001  23.0.0.3        12.0.0.1               ACTIVE aes  sha    psk  2  00:29:54
       Engine-id:Conn-id =  SW:1

IPv6 Crypto ISAKMP SA

Above output is taken as soon as the tunnel is build - and thats how I know the policy with lifetime of 1800 is chosen. There are times when 3des is chosen as well:

R3#sh crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       T - cTCP encapsulation, 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.

1001  23.0.0.3        12.0.0.1               ACTIVE 3des sha    psk  2  23:57:21
       Engine-id:Conn-id =  SW:1

IPv6 Crypto ISAKMP SA

I want it to use AES-256 with default SHA and lifetime value, which is the topmost policy in R1. Is there anything that I have missed in the config to make the policy selection more deterministic? Thanks.

Haris

[Vishnu Sharma · Accepted solution]

Hi Haris,

The behavior is correct. If R1 initiates the connection, it will send the first isakmp policy i.e. AES/SHA/Grp-2/Pre-share/Lifetime and once this will reach R3, R3 will scan policies configured for it and will scan from 10 to 50. It will get a match on 40. So AES with SHA is selected. 

When R3 becomes initiator, 3DES/SHA/Grp2/Pre-share/Lifetime will be the first one in the match list (as it is first in the list with policy 10; policy 1 is incomplete). When the same will be scanned on R1 for match, it will get match on policy 20. 

Now, you want AES/SHA/Group2/Pre-share to be selected everytime, then on R3, create a policy with lowest number.

For ex.

crypto isakmp policy 1
 encr aes 256
 authentication pre-share
 group 2
 lifetime 1800
 hash sha

When you apply this command, it will remove existing isakmp policy 1 however it will make no difference because isakmp policy 1 is incomplete. Please try this and let me know if this fixes your problem.

Thanks,

Vishnu 

[Haris Hilmi Abdul Rahim]

Thanks Vishnu.

What I still does not understand is, why when R1 initiates the connection, it chooses Policy 40 with lifetime=1800, instead of going down to Policy 50, where it has default lifetime of 86400. Shouldn't lifetime be matched as well?
 

That's a very good suggestion to prioritize the policy further by increasing policy number, but if R3 is a hub router with many other spokes IPSec peers, I worry that some other connections will be affected. 

Thanks.

[johnlloyd_13 · Accepted solution]

hi,

R1 and R3 IKE phase 1 policy matched on policy 10 and 40 respectively.

just like an ACL, it runs sequentially and stops on the first match.

the IPsec VPN will always go for the lowest negotiated lifetime which is 1800 seconds vs the default 86400 sec (1 day).

see helpful link:

http://ccnpsecuritywannabe.blogspot.com/2014/08/ikev1-ipsec-site-to-site-vpn.html

[Haris Hilmi Abdul Rahim]

Hi John, 

This is new to me. I tested the connection with different lifetimes configured and yes, the lower negotiated lifetime was chosen. Thanks!