'crypto keyring' limit for VRF on IOS router

[johnlloyd_13]

hi,

i got a 2911 router which currently has a site-to-site VPN working using the 'crypto keyring vrf' (for VRF aware IPSEC).

i need to add another site (CUST-2) using the same command but different VRF (CUST-2) but getting the log and deug below. i already made sure the remote config is fine and re-applied the PSK on both ends but still no SA.

my question is, is there a limit on the number of VRF allowed locally on an IOS router (2911 in this case) to use the 'crypto keyring vrf' command? is it limited to just one VRF?

i tried using the 'native' or global RT for 'crypto isakmp key' and the 'crypto isakmp profile' but still no SA.

crypto keyring CUST-1 vrf CUST-1
 pre-shared-key address 20.x.x.4 key <KEY-1>

crypto keyring CUST-2 vrf CUST-2
 pre-shared-key address 202.x.x.41 key <KEY-2>

crypto map CMAP 10 ipsec-isakmp
set peer 20.x.x.4
set transform-set TSET-AES-SHA
match address <ACL-1>

crypto map CMAP 20 ipsec-isakmp
set peer 202.x.x.41
set transform-set TSET-AES-SHA
match address <ACL-2>

.Feb 9 11:07:49.692 UTC: %CRYPTO-6-IKMP_NO_PRESHARED_KEY: Pre-shared key for remote peer at 202.x.x.41 is missing

.Feb 9 10:32:12.470 UTC: ISAKMP:(0):No pre-shared key with 202.x.x.41!
.Feb 9 10:32:12.470 UTC: %CRYPTO-6-IKMP_NO_PRESHARED_KEY: Pre-shared key for remote peer at 202.x.x.41 is missing
.Feb 9 10:32:12.470 UTC: ISAKMP : Scanning profiles for xauth ...
.Feb 9 10:32:12.470 UTC: ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
.Feb 9 10:32:12.470 UTC: ISAKMP: default group 2
.Feb 9 10:32:12.470 UTC: ISAKMP: encryption AES-CBC
.Feb 9 10:32:12.470 UTC: ISAKMP: keylength of 128
.Feb 9 10:32:12.470 UTC: ISAKMP: hash SHA
.Feb 9 10:32:12.470 UTC: ISAKMP: auth pre-share
.Feb 9 10:32:12.470 UTC: ISAKMP: life type in seconds
.Feb 9 10:32:12.470 UTC: ISAKMP: life duration (VPI) of 0x0 0x0 0xA8 0xC0
.Feb 9 10:32:12.470 UTC: ISAKMP:(0):Preshared authentication offered but does not match policy!
.Feb 9 10:32:12.470 UTC: ISAKMP:(0):atts are not acceptable. Next payload is 0
.Feb 9 10:32:12.470 UTC: ISAKMP:(0):no offers accepted!
.Feb 9 10:32:12.470 UTC: ISAKMP:(0): phase 1 SA policy not acceptable! (local 61.x.x162 remote 202.x.x.41)

[Rob Ingram]

Hi @johnlloyd_13 do you have an ISAKMP profile for this new VPN, with the specific vrf defined?

[johnlloyd_13]

hi rob,

as mentioned, i tried that approach but no SA.

crypto isakmp profile <CUST-2>
vrf <CUST-2>
keyring<CUST-2>
match identity address 202.x.x.41 255.255.255.255 <CUST-2>

crypto map CMAP 20 ipsec-isakmp
 set isakmp-profile <CUST-2>

[Rob Ingram]

@johnlloyd_13 you can certainly match against more than one vrf.

What is the configuration of the physical interfaces?

I assume you've double checked the ISAKMP Policy matches the algorithms on both ends?

[johnlloyd_13]

hi rob,

yes IKE phase 1 and 2 are same on both ends.

it's just the crypto map applied on the WAN/ISP interface. is it because CUST-1 VRF is applied on the WAN?

although i got 'tunnel vrf CUST-1' applied on the tunnel used by CUST-2.

2911#sh run int g0/1
Building configuration...

Current configuration : 226 bytes
!
interface GigabitEthernet0/1
ip vrf forwarding CUST-1
ip address 61.x.x.x162 255.255.255.252
duplex full
speed 100
crypto map CMAP
!
end

interface Tunnel8
ip vrf forwarding CUST-2
ip address 172.x.x.4 255.255.255.252
ip tcp adjust-mss 1360
tunnel source 172.x.x.16
tunnel destination 172.x.x.17
tunnel vrf CUST-1

[Rob Ingram]

@johnlloyd_13 then surely the keyring for the new VPN should be in CUST-1 vrf?

CUST-2 is the inside vrf for cleartext traffic, but CUST-1 is the outside interface where the VPN terminates. Right?

[MHM Cisco World]

Sorry, can you just clear this, are you use one interface for crypto map or two interface?

[johnlloyd_13]

hi,

i only created a single crypto map applied on g0/1 interface which is facing ISP.

g0/1 is using CUST-1 VRF.

[MHM Cisco World]

That issue i think, 

Use loopback with vrf for each vpn,

Use this loopback as source for ipsec,

Make the outside interface in global.

This way the outside recive the ipsec and check the peer with vrf and use loopback to reply 

[johnlloyd_13]

hi,

i managed to resolve it.

just added another PSK line under the same 'crypto keyring'

2911(conf-keyring)#do sh run | s crypto
crypto keyring CUST-1 vrf CUST-1
pre-shared-key address 20x.x.x.4 key <KEY-1>
pre-shared-key address 202.x.x..41 key <KEY-2>

[MHM Cisco World]

This way two vpn same vrf,

If it ok for you it work.

[ricardo.minier]

my case was with vrf,  if you have a vrf configured which I guess you are because you are getting the same logs than me you have to source the keyring from the vrf 

crypto keyring my_keyring vrf MY_VRF
pre-shared-key address x.x.x.x key password