Cisco ASR (IOS XE) using the incorrect "ikev2 policy" & "ikev2 proposal"

[kasunrajapakse]

Hi Team, 

Following is the IPSec config I have on my ASR. There are multiple "ikev2 policies" calling multiple "ikev2 proposals" - This is just one set of them.  Each IKev2 Policy and IKev2 Proposal is configured with different parameters for each peer. 

My issue is that, the Cisco ASR doesn't match the correct IKEv2 Policy. It's trying to use a different IKev2 Policy and hence not being able to get Phase 1 up.  The only way to fix the issue is to amend the parameters on the of the Policy / Proposal it is trying to couple with. (When I do a debug, I can see what IKEv2 Policy it is trying to couple with) 

Any idea how to fix ? Troubleshoot this issue? I have also noticed that "crypto ikev2 policy IKEv2_Policy_GARBUTT_LEEDS" is never called anywhere in the config. So I would assume that this is configured Globally.  

There are multiple policies / proposals configured - But it doesn't pick the right Policy .



crypto ikev2 proposal Proposal_GE_Leeds
encryption aes-cbc-256
integrity sha1
group 5

crypto ikev2 policy IKEv2_Policy_GARBUTT_LEEDS
match fvrf FVRF
match address local 62.x.x.x
proposal Proposal_GE_Leeds

crypto ikev2 keyring Keyring_GE_Leeds
peer Peer_Garbutt_Leeds
address 185.x.x.x
pre-shared-key abc123
!

crypto ikev2 profile IKEv2_Profile_GE_Leeds
match fvrf FVRF
match address local interface Loopback2
match address local 62.x.x.x
match identity remote address 185.x.x.x 255.255.255.255
authentication remote pre-share
authentication local pre-share
keyring local Keyring_GE_Leeds

crypto ipsec transform-set TS_GE_Leeds esp-aes 256 esp-sha-hmac
mode tunnel

crypto ipsec profile IPsec_Profile_Garbutt_Leeds
set transform-set TS_GE_Leeds
set pfs group5
set ikev2-profile IKEv2_Profile_GE_Leeds
reverse-route

ip access-list extended IPSec_ACL_GE_Leeds
10 permit ip 10.113.25.0 0.0.0.15 10.9.3.0 0.0.0.255
20 permit ip 10.113.13.232 0.0.0.7 10.9.3.0 0.0.0.255
30 permit ip 10.113.13.240 0.0.0.7 10.9.3.0 0.0.0.255
40 permit ip 10.113.15.208 0.0.0.15 10.9.3.0 0.0.0.255
50 permit ip 10.113.15.176 0.0.0.7 10.9.3.0 0.0.0.255
60 permit ip 10.113.15.184 0.0.0.7 10.9.3.0 0.0.0.255

interface Tunnel 4
description IKEv2 IPSec Ga_E - Leeds
vrf forwarding garbutt_leeds
ip unnumbered Port-channel1.1760
zone-member security GARBUTT_LEEDS
tunnel source Loopback2
tunnel mode ipsec ipv4
tunnel destination 185.x.x.x
tunnel vrf FVRF
tunnel protection ipsec policy ipv4 IPSec_ACL_GE_Leeds
tunnel protection ipsec profile IPsec_Profile_Garbutt_Leeds
end

[Rob Ingram]

@kasunrajapakse 

You don't specifically call the IKEv2 Policy anywhere else in the configuration, you just define a proposal and reference that in the policy.

I notice you have a FVRF, is the tunnel source interface configured in that VRF?

Can you provide your IKEv2 debugs and the output of "show crypto ikev2 policy"?

You can disable the smart defaults - "no crypto ikev2 proposal default" and "no crypto ikev2 policy default".

FYI, don't use DH group 5, it's weak and depreciated in newer OS versions, also SHA1 is considered weak. If you are using IKEv2, you might as well be using AES-GCM, DH groups 21,20 or 19 etc.

[kasunrajapakse]

Hi Rob,

I notice you have a FVRF, is the tunnel source interface configured in that VRF? 

        Yes. The same vrf. 

Can you provide your IKEv2 debugs and the output of "show crypto ikev2 policy"?

ASR#show crypto ikev2 policy
IKEv2 policy : IKEv2_Policy_GARBUTT_LEEDS

Match fvrf : FVRF
Match address local : 62.x.x.x
Proposal : Proposal_GE_Leeds

IKEv2 policy : Policy_HF_Test_AR
Match fvrf : FVRF
Match address local : 62.x.x.x
Proposal : Proposal_HF_Test_AR

What is the configuration of the peer router, does it have the same policies?
It's a different vendor. Yes. they have the same policies. 

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

To give you some background info, the remote end saw 3DES encryption coming. So I knew the ASR wasn't using the correct Policy / Proposal. "IKEv2 policy : Policy_HF_Test_AR " was the only Policy that had 3DES on it's proposal as shown below. 

Before

crypto ikev2 proposal Proposal_GE_Leeds
encryption aes-cbc-256
integrity sha1
group 5

crypto ikev2 proposal Proposal_HF_Test_AR
encryption 3des
integrity sha1
group 2

After

crypto ikev2 proposal Proposal_HF_Test_AR
encryption aes-cbc-256
integrity sha1
group 5

I changed the parameters on this proposal (Proposal_HF_Test_AR) as per the remote end. Even thought this was not the proposal that it was supposed to use. The IPSec worked fine after that. 

In Summary : The ASR was trying to match "IKEv2 policy : Policy_HF_Test_AR " which obviously had different parameters in it's proposal. But I didn't know how to make the ASR pick "IKEv2 policy : IKEv2_Policy_GARBUTT_LEEDS". So I changed the parameters in the Policy / Proposal that it was trying to match. 

The IPSec is working fine now. After I changed the parameters of another IKev2 Proposal. 
But I can't have this happening in the long run because I have multiple IKev2 Polices and IKev2 Proposals. I need the ASR to pick the correct IKev2 Policy and then the respective Ikev2 proposal defined. 

[Rob Ingram]

If the peer initiated the connection they will send all it's proposals it supports, one of which sounds like it was 3DES, SHA1, DH2. If that was the peers preferred proposals, then the IKEv2 SA would be established using 3DES, SHA, DH 2. By changing your policy, you no longer support those ciphers so would obviously use the next proposals you both support.

[kasunrajapakse]

,

[Rob Ingram]

Oh ok I think I understand what you are saying now. You've got the same match conditions on the ikev2 policies, there is no unique "match" to distinguish between them. Therefore the ikev2 policy that used the 3DES proposal was selected, the other ikev2 policy is not processed.

If you have multiple VPNs with different proposals, you would have to configure 1 ikev2 policy with those 2 match statements, then reference the different proposals. When a IKEv2 negotiation takes place it will offer all the proposals listed.

crypto ikev2 policy IKEv2_Policy
 match fvrf FVRF
 match address local 62.x.x.x
 proposal Proposal_GE_Leeds
 proposal Proposal_HF_Test_AR

[kasunrajapakse]

Hi Rob,

Okay that makes sense. 

" You've got the same match conditions on the ikev2 policies, there is no unique "match" to distinguish between them."  - Can we not define any statement to match that particular peer?  Looks like only the Local IP addresses can be matched (which will be the same for multiple VPNs)
ASR(config-ikev2-policy)#match address ?
local    Local address


If this is not possible, what you are suggesting is to create one Global IKev2 Policy and then define all the proposals (depending on the Phase 1 parameters) So whenever a request comes, it will check the IKev2 Policy and offer the matching proposal?   - Is this the only way? 

Can we not specify what Policy / Proposal to be picked depending on the specific remote peer? 

[Rob Ingram · Accepted solution]

Correct the ikev2 policies are global, you cannot currently create a per-policy based on remote peer....you cannot even do that on ASA or FTD.

[kasunrajapakse]

Thank you very much for your help Rob. 
Appreciate it greatly. 

[kasunrajapakse]

.