IPsec phase2 issue with DMVPN on Catalyst 8200

[George Tchkoidze]

Hello,

I've Upgraded ISR 4300 series DMVPN hub to Catalyst 8200 series. Spokes are ISR 4300 (Version 16.12.05). After upgrade, spokes are not registering with the hub, when using tunnel protection.

I tried to strip of protection from the DMVPN tunnel and it worked.

I tried to setup GRE tunnel with ipsec protection (same ipsec profile as DMVPN) between the same hub and spoke and it worked, But when I try to add the ipsec profile to DMVPN tunnel, it doesn't work.

These are the related debug output:

Jan 30 08:05:59.826: ISAKMP-ERROR: (18391):IPSec policy invalidated proposal with error 64 Jan 30 08:05:59.826: ISAKMP-ERROR: (18391):phase 2 SA policy not acceptable! (local ********* remote *********) Jan 30 08:05:59.826: ISAKMP: (18391):set new node 402208052 to QM_IDLE

In fact, phase2 config matches between HUB and Spoke.

Tried to upgrade HUB router to Version 17.09.04a, without a success. One interesting fact, when spoke is same hardware (Catalyst 8200), DMVPN with protection works.

[MHM Cisco World]

Add tunnel key in both hub and spoke 

Make sure the hub use isakmp key address 0.0.0.0

MHM

[tvotna]

So, basically, p-to-p GRE tunnel works with tunnel protection and mGRE tunnel doesn't come up, because IPSec SA fails to establish, with the same IPSec profile, right?

Do you use tunnel IPSec mode or transport mode for the IPSec profile? Do you have NAT in between? Do you have other tunnels on the hub which share tunnel source with mGRE tunnel? Do you use IKEv1 or IKEv2?

[George Tchkoidze]

Tunnel key is there for both sides, hub uses isakmp key address 0.0.0.0.

Correct, mGRE tunnel doesn't come up, because IPSec SA fails to establish.

I use IPSec transport mode and IKEv1. No NAT in between, no other tunnels on both side which shares tunnel source or destinetion with mGRE.

[MHM Cisco World]

Did you config  Ip nhrp nhs whrn you config mGRE DMVPN?

Did you config ip nhrp map correctly?

MHM

[George Tchkoidze]

NHRP config is done correctly. When I strip of the protection from the DMVPN tunnel, tunnel goes up and works as expected.

[MHM Cisco World]

Are you use sharad keyword witg ipsec profile?

If yes remove it 

MHM

[MHM Cisco World]

I thinking in your issue in way to home' 

The keyring you use 0.0.0.0 but still last part which is ikev2 profile remote identity this also need to be 0.0.0.0

Check this link 

https://journey2theccie.wordpress.com/2020/03/13/ikev1-ikev2-configuration-in-dmvpn/

MHM

[tvotna]

It's really hard to say what's going on. Perhaps we either need configuration from both sides and complete conditional debug output from both sides, or you need to open a TAC case.

show crypto isakmp policy
show crypto ipsec profile
show crypto ipsec transform-set

debug dmvpn condition peer nbma <IP>
debug dmvpn detail all

[George Tchkoidze]

I don't use shared keyword with ipsec profile.

I use ikev1, not ikev2.

I have opened TAC case, but got no solution so far.

I've attached config and debug file, which is session I had with TAC.

[MHM Cisco World]

friend we will not solve this issue if we continuous this way 
I assume you config this and that not solve issue 
please share the config of tunnel and ikev2 keyring, ikev2 policy, ikev2 porfile, ipsec profile 
let check point by point 
note:-if there is public IP hided it and also hide the password 
MHM

[tvotna]

Hmm... Why does ISAKMP on the Hub prints correct lifetime initially (3600), but then IPSec prints it as 0?

Jan 30 08:05:59.825: ISAKMP-PAK: (18391):received packet from 178.134.69.254 dport 500 sport 500 Global (R) QM_IDLE 
Jan 30 08:05:59.825: ISAKMP: (18391):set new node 2592257252 to QM_IDLE 
Jan 30 08:05:59.825: ISAKMP: (18391):processing HASH payload. message ID = 2592257252
Jan 30 08:05:59.825: ISAKMP: (18391):processing SA payload. message ID = 2592257252
Jan 30 08:05:59.825: ISAKMP: (18391):Checking IPSec proposal 1
Jan 30 08:05:59.825: ISAKMP: (18391):transform 1, ESP_AES 
Jan 30 08:05:59.825: ISAKMP: (18391): attributes in transform:
Jan 30 08:05:59.825: ISAKMP: (18391): encaps is 1 (Tunnel)
Jan 30 08:05:59.825: ISAKMP: (18391): SA life type in seconds
Jan 30 08:05:59.825: ISAKMP: (18391): SA life duration (basic) of 3600
Jan 30 08:05:59.825: ISAKMP: (18391): SA life type in kilobytes
Jan 30 08:05:59.825: ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0 
Jan 30 08:05:59.825: ISAKMP: (18391): authenticator is HMAC-SHA256
Jan 30 08:05:59.825: ISAKMP: (18391): key length is 256
Jan 30 08:05:59.825: ISAKMP: (18391):atts are acceptable.
Jan 30 08:05:59.825: IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) INBOUND local= 45.157.153.254:0, remote= 178.134.69.254:0,
local_proxy= 45.157.153.254/255.255.255.255/47/0,
remote_proxy= 178.134.69.254/255.255.255.255/47/0,
protocol= ESP, transform= esp-aes 256 esp-sha256-hmac (Tunnel), esn= FALSE,
lifedur= 0s and 0kb, 
spi= 0x0(0), conn_id= 0, keysize= 256, flags= 0x0
Jan 30 08:05:59.826: IPSEC(ipsec_process_proposal): peer address 178.134.69.254 not found
Jan 30 08:05:59.826: ISAKMP-ERROR: (18391):IPSec policy invalidated proposal with error 64
Jan 30 08:05:59.826: ISAKMP-ERROR: (18391):phase 2 SA policy not acceptable! (local 45.157.153.254 remote 178.134.69.254)
Jan 30 08:05:59.826: ISAKMP: (18391):set new node 402208052 to QM_IDLE 
Jan 30 08:05:59.826: ISAKMP: (18391):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3
spi 9223512609231794816, message ID = 402208052

Does tunnel source 45.157.153.254 live in the global routing table on the Hub? What is corresponding egress physical interface?

R2#sh ip int br | in 45.157.153.254
Loopback254 45.157.153.254 YES NVRAM up up

It appears this loopback is used as a tunnel source for many different tunnel interfaces. What are they? P-to-p SVTI tunnels to other sites which are routed through many different GigabitEthernet0/0/1 subinterfaces? Just want to make sure you don't have legacy crypto maps applied to them.

I'm sure TAC will be able to tell you what "error 64" is about.