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!
