cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
391
Views
0
Helpful
4
Replies

DMVPN+IPSec isakmp phase 2 not working

MysticalTh0r
Level 1
Level 1

Hello everyone,

We have a couple of Cisco routers working fine in a DMVPN multi vrf topology. We have recently installed a 3rd router, which will replace one of the previous ones and we are unable to make it work through the VRF (it works as expected on the global routing table).

After debugging, we have seen a phase 2 error, which it should mean transform set discrepancy among this router and the spokes, but we have checked it and it's the same as the other hub routers and the spokes:

The debugs:

May 9 15:46:42.890 METDST: ISAKMP: (1149):set new node 897370415 to QM_IDLE
May 9 15:46:42.890 METDST: ISAKMP: (1149):processing HASH payload. message ID = 897370415
May 9 15:46:42.890 METDST: ISAKMP: (1149):processing SA payload. message ID = 897370415
May 9 15:46:42.890 METDST: ISAKMP: (1149):Checking IPSec proposal 1
May 9 15:46:42.890 METDST: ISAKMP: (1149):transform 1, ESP_AES
May 9 15:46:42.890 METDST: ISAKMP: (1149): attributes in transform:
May 9 15:46:42.890 METDST: ISAKMP: (1149): encaps is 1 (Tunnel)
May 9 15:46:42.890 METDST: ISAKMP: (1149): SA life type in seconds
May 9 15:46:42.890 METDST: ISAKMP: (1149): SA life duration (basic) of 18000
May 9 15:46:42.890 METDST: ISAKMP: (1149): SA life type in kilobytes
May 9 15:46:42.890 METDST: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0
May 9 15:46:42.891 METDST: ISAKMP: (1149): authenticator is HMAC-SHA
May 9 15:46:42.891 METDST: ISAKMP: (1149): key length is 128
May 9 15:46:42.891 METDST: ISAKMP: (1149):atts are acceptable.
May 9 15:46:42.891 METDST: ISAKMP-ERROR: (1149):IPSec policy invalidated proposal with error 32
May 9 15:46:42.892 METDST: ISAKMP-ERROR: (1149):phase 2 SA policy not acceptable! (local 10.200.8.33 remote 10.200.8.10)

Config on the hub router (not working):

We receive the loopback interface of the spoke on the routing table: 

sh ip route vrf VRF_MX 10.200.8.10

Routing Table: VRF_MX
Routing entry for 10.200.8.10/32

interface Tunnel1
ip vrf forwarding VRF_MX
ip address 10.200.9.3 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication cisco321
ip nhrp network-id 3
ip nhrp server-only
ip nhrp redirect
ip tcp adjust-mss 1360
tunnel source Loopback800
tunnel mode gre multipoint
tunnel key 11
tunnel vrf VRF_MX
tunnel protection ipsec profile vpnprof_VRF1

crypto ipsec profile vpnprof_VRF1
set transform-set transformada_MX
set isakmp-profile PROF

crypto ipsec transform-set transformada_MX esp-aes esp-sha-hmac
mode tunnel

crypto isakmp profile PROF
vrf VRF_MX
keyring KEYRING
match identity address 0.0.0.0
local-address 10.200.9.3

interface Loopback800  <-- Source of the tunnel, in the proper VRF
ip vrf forwarding VRF_MX
ip address 10.200.8.3 255.255.255.255

 

 

Config on the spoke (there's no VRF):

We receive the loopback interface of the spoke on the routing table: 

sh ip route 10.200.8.3
Routing entry for 10.200.8.3/32

interface Tunnel1
ip address 10.200.9.10 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication cisco321
ip nhrp map 10.200.9.2 10.200.8.2 <-- HUB 2 , working
ip nhrp map multicast 10.200.8.2
ip nhrp map 10.200.9.1 10.200.8.1 <-- HUB 1 , working
ip nhrp map multicast 10.200.8.1
ip nhrp map 10.200.9.3 10.200.8.3 <-- HUB 3 , not working
ip nhrp map multicast 10.200.8.3
ip nhrp network-id 3
ip nhrp holdtime 600
ip nhrp nhs 10.200.9.1
ip nhrp nhs 10.200.9.3
ip nhrp nhs 10.200.9.2
ip nhrp shortcut
ip tcp adjust-mss 1360
tunnel source Loopback700
tunnel mode gre multipoint
tunnel key 11
tunnel protection ipsec profile vpnprof

crypto ipsec profile vpnprof
set transform-set transformada
set isakmp-profile PROF

crypto ipsec transform-set transformada esp-aes esp-sha-hmac
mode tunnel

crypto isakmp profile PROF
keyring KEYRING
match identity address 0.0.0.0
local-address 10.200.9.10

The hub was running IOS 16.9.4 and we upgraded to 16.9.8 just as a test, same results. We've seen the following bug, which has not listed our current IOS version on the affected ones , but it's very recent (may 1st 2024)

CSCwj88872 : Bug Search Tool (cisco.com)

Symptom: A DMVPN hub router is failing IPsec negotiation with the spoke routers after a software upgrade from IOS-XE 17.3 to 17.9 code. Even though the configuration is correct, IPsec still fails to negotiate due to unacceptable policy: ISAKMP-ERROR: (43547):IPSec policy invalidated proposal with error 32 ISAKMP-ERROR: (43547):phase 2 SA policy not acceptable! (local x.x.x.x remote y.y.y.y) This is only an issue in IOS-XE 17.9 and later code.

Any suggestions? Would it be worth the try to upgrade to IOS 17.3 just in case? Another hypothesis would be that only 2 hubs are allowed on the same DMVPN and this is the reason why a 3rd hub is not working?

Thanks!

 

 

 

 

 

 

1 Accepted Solution

Accepted Solutions

MysticalTh0r
Level 1
Level 1

I tried out to configure IKEv2 following this bug https://bst.cisco.com/bugsearch/bug/CSCwj88872

After that, it started working but I may have some loop with the BGP on the spokes, since as soon as the IP tunnels are pingable, the BGP session with the spoke comes up and after some seconds , IP tunnels are no longer pingable. My money is on that the spoke is advertising the network of the tunnels via BGP, but not sure why it messes up with the routing on the hub, since it already knows this network via connected.

But this is another matter, the problem of DMVPN seems clear to be affected by the bug, since after configuring IKEv2 it started working properly.

Thanks for the help! Best regards.

 

View solution in original post

4 Replies 4

https://www.google.com/amp/ttl255.com/dmvpn-and-ipsec-with-front-door-vrf/amp/

Check this link

You need to config kerying vrf aware of isakmp

That what I see missing only

MHM

MysticalTh0r
Level 1
Level 1

Thanks for the information.

I thought isakmp profile was already vrf aware since its config was:

crypto isakmp profile PROF
vrf VRF_MX  <-- VRF (not included on the spoke since it has no VRF)
keyring KEYRING
match identity address 0.0.0.0
local-address 10.200.9.3

However I saw that VRF can also be included on the "match identity", so I tried with no luck (deleting and including vrf VRF_MX)

I see the same error.

May 10 08:26:14.755 METDST: ISAKMP-ERROR: (1160):IPSec policy invalidated proposal with error 32
May 10 08:26:14.756 METDST: ISAKMP-ERROR: (1160):phase 2 SA policy not acceptable! (local 10.200.8.3 remote 10.200.8.10)

 

Debug dmvpn detail 

Share above for hub and spoke 

Note:- for hub use 

Debug dmpvn condition peer <peer ip> 

To make debug show only log of specific peer not all peers

MHM

MysticalTh0r
Level 1
Level 1

I tried out to configure IKEv2 following this bug https://bst.cisco.com/bugsearch/bug/CSCwj88872

After that, it started working but I may have some loop with the BGP on the spokes, since as soon as the IP tunnels are pingable, the BGP session with the spoke comes up and after some seconds , IP tunnels are no longer pingable. My money is on that the spoke is advertising the network of the tunnels via BGP, but not sure why it messes up with the routing on the hub, since it already knows this network via connected.

But this is another matter, the problem of DMVPN seems clear to be affected by the bug, since after configuring IKEv2 it started working properly.

Thanks for the help! Best regards.

 

Review Cisco Networking for a $25 gift card