cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3296
Views
0
Helpful
2
Replies

IKEv2 DVTI to SVTI in a VRF

Radu Stefan
Level 1
Level 1

Hi,

I have the following test setup:

3945 ------- 7600 ------- ASR1001

On the 3945 I have lots (~100 each) of FVRFs and IVRFs configured.

On the 7600 lots of subinterfaces facing the 3945 FVRFs and 1 subinterface towards the ASR, all in a single VRF - simulating an Internet connectivity.

On the ASR I have a single FVRF (connected to the 7600) and a single IVRF to terminate all these tunnels.

The 3945 is supposed to simulate lots of CPEs connected on the ASR which is acting as a hub.

I'm using IKEv2 for the IPSEC tunnels and the configuration works fine when I'm using SVTI on both sides or when using a non-vrf configuration on the 3945.

When I change the configuration on the ASR side and use a virtual-template and RADIUS, I get the following debug messages on the ASR:

Jan 21 16:10:49.103 gmt: IKEv2:(SA ID = 2):Session with IKE ID PAIR (vrf1.ipsec.net, PE-IKE) is UP

Jan 21 16:10:49.103 gmt: IKEv2:(SA ID = 2):Initializing DPD, configured for 60 seconds

Jan 21 16:10:49.103 gmt: IKEv2:IKEv2 MIB tunnel started, tunnel index 2

Jan 21 16:10:49.103 gmt: IKEv2:Store mib index ikev2 2, platform 1569

Jan 21 16:10:49.103 gmt: IKEv2:(SA ID = 2):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (R) MsgID = 00000001 CurState: AUTH_DONE Event: EV_CHECK_DUPE

Jan 21 16:10:49.103 gmt: IKEv2:(SA ID = 2):Checking for duplicate IKEv2 SA

Jan 21 16:10:49.103 gmt: IKEv2:(SA ID = 2):No duplicate IKEv2 SA found

Jan 21 16:10:49.112 gmt: IKEv2:IKEv2 tunnel 2 stop, platform index 1569 reason 4

And on the 3945:

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Session with IKE ID PAIR (PE-IKE, vrf1.ipsec.easynet.net) is UP

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Initializing DPD, configured for 30 seconds

*Jan 21 16:25:06.568 UTC: IKEv2:IKEv2 MIB tunnel started, tunnel index 1

*Jan 21 16:25:06.568 UTC: IKEv2:Store mib index ikev2 1, platform 38

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: AUTH_DONE Event: EV_CHECK_DUPE

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Checking for duplicate IKEv2 SA

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):No duplicate IKEv2 SA found

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: AUTH_DONE Event: EV_CHK4_ROLE

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: READY Event: EV_CHK_IKE_ONLY

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: READY Event: EV_DEL_SA

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Queuing IKE SA delete request reason: unknown

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: READY Event: EV_FREE_NEG

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Deleting negotiation context for my message ID: 0x1

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: READY Event: EV_IPSEC_DEL

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Action: Action_Null

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: INFO_I_BLD_INFO Event: EV_SND_IPSEC_DEL

*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Sending DELETE INFO message for IPsec SA [SPI: 0xB15D57D0]

So it looks it's passing IKE then - for an unknown reason - IKE SAs are deleted.

IOS wise, I'm using 3.7.2 on the ASR and 15.2(4)M2 on the 3945.

Configs are:

ASR:

crypto ikev2 profile IKE-SVTI

match fvrf FVRF-SVTI

match identity remote fqdn domain ipsec.net

identity local key-id PE-IKE

authentication remote pre-share

authentication local pre-share

keyring aaa IPSEC-AUTHOR

aaa authorization user psk cached

virtual-template 2

crypto ipsec transform-set TFS-AES256-SHA-HMAC esp-aes 256 esp-sha-hmac

mode tunnel

crypto ipsec profile IKE-SVTI

set transform-set TFS-AES256-SHA-HMAC

set ikev2-profile IKE-SVTI

responder-only

interface Virtual-Template2 type tunnel

vrf forwarding test-svti

no ip address

tunnel source GigabitEthernet0/0/2.611

tunnel mode ipsec ipv4

tunnel vrf FVRF-SVTI

tunnel protection ipsec profile IKE-SVTI

end

I've tried the following:

- removing the vrf config from the Virtual-Template inteface (my initial config)

- adding the VRF to the IKE profile

RADIUS:

vrf1.ipsec.net

        Tunnel-Password = 3945,

        Framed-IP-Address=192.168.40.2,

        Framed-IP-Netmask=255.255.255.252,

        cisco-avpair="ip:interface-config=vrf forwarding test-svti",

        cisco-avpair="ip:interface-config=ip address 192.168.40.1 255.255.255.252",

3945:

crypto ikev2 keyring IKE-KEYRING

peer ASR.VRF1

  address 213.201.141.3

  pre-shared-key 3945

!

crypto ikev2 profile IKE-VRF1

match fvrf FVRF1

match identity remote key-id PE-IKE

identity local fqdn vrf1.net

authentication remote pre-share

authentication local pre-share

keyring local IKE-KEYRING

!

crypto ipsec profile IKE-VRF1

set transform-set TFS-AES256-SHA-HMAC

set ikev2-profile IKE-VRF1

!

interface Tunnel401

ip vrf forwarding VRF1

ip address 192.168.40.2 255.255.255.252

tunnel source GigabitEthernet0/1.401

tunnel mode ipsec ipv4

tunnel destination 213.201.141.3

tunnel vrf FVRF1

tunnel protection ipsec profile IKE-VRF1

I've tried using "ip address negotiated" on the SVTI interface on the 3945 (my initial setup).

If I configure the ASR part as SVTI, everything works fine. Also, the RADIUS part works fine, I used it for non-VRF setup on the CPE.

The only configuration that fails is with VRFs on the 3945 side.

So I'm wondering if there is a limitation for this setup in terms of terminating both ends inside VRFs?

From the debugs I'm not clear which side decides to cut the SA.

Thank you,

Radu


2 Replies 2

Radu Stefan
Level 1
Level 1

To add more information to this:

- SVTI to SVTI works fine in exactly the same setup explained above (with VRFs on the CPE).

When I change it to DVTI on the PE (just by adding the virtual-template command to the IKE profile) the IPSEC cannot be established, IKEv2 passes OK then it drops when IPSEC is negociated.

SVTI config on the PE:

crypto ikev2 profile IKE-SVTI

match fvrf FVRF-SVTI

match identity remote fqdn domain ipsec.net

identity local key-id PE-IKE

authentication remote pre-share

authentication local pre-share

keyring aaa IPSEC-AUTHOR

aaa authorization user psk cached

!

crypto ipsec profile IKE-SVTI

set transform-set TFS-AES256-SHA-HMAC

set ikev2-profile IKE-SVTI

responder-only

!

interface Tunnel401

vrf forwarding test-svti

ip address 192.168.40.1 255.255.255.252

tunnel source GigabitEthernet0/0/2.611

tunnel mode ipsec ipv4

tunnel destination 172.20.0.2

tunnel vrf FVRF-SVTI

tunnel protection ipsec profile IKE-SVTI

end

DVTI config on the PE:

crypto ikev2 profile IKE-DVTI

match fvrf FVRF-SVTI

match identity remote fqdn domain ipsec.net

identity local key-id PE-IKE

authentication remote pre-share

authentication local pre-share

keyring aaa IPSEC-AUTHOR

aaa authorization user psk cached

virtual-template 2

crypto ipsec profile IKE-DVTI

set transform-set TFS-AES256-SHA-HMAC

set ikev2-profile IKE-DVTI

interface Virtual-Template2 type tunnel

no ip address

tunnel source GigabitEthernet0/0/2.611

tunnel mode ipsec ipv4

tunnel vrf FVRF-SVTI

tunnel protection ipsec profile IKE-DVTI

end

RADIUS account:

vrf001.ipsec.net

        Tunnel-Password = 3945,

        cisco-avpair="ip:interface-config=vrf forwarding test-svti",

        cisco-avpair="ip:interface-config=ip address 192.168.40.1 255.255.255.252",

CPE config is kept the same for either SVTI/DVTI tests on the ASR, RADIUS account is the same in both cases.

A "debug crypto ike error" shows the following on the ASR (PE), when DVTI is used:

Jan 22 10:15:49.278 gmt: %IKEV2-5-SA_UP: SA UP

Jan 22 10:15:49.288 gmt: IKEv2:(SA ID = 4):There was no IPSEC policy found for received TS

Jan 22 10:15:49.288 gmt: IKEv2:(SA ID = 4):

Jan 22 10:15:49.288 gmt: %IKEV2-5-SA_UP: SA UP

Jan 22 10:15:49.289 gmt: %IKEV2-5-SA_DOWN: SA DOWN

Any ideeas?

I had exactly the same issue in our lab environment. Try configuring the remote as DVTI as well.