02-15-2024 03:06 AM
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.
02-15-2024 03:37 AM
Add tunnel key in both hub and spoke
Make sure the hub use isakmp key address 0.0.0.0
MHM
02-15-2024 06:23 AM
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?
02-16-2024 12:34 AM
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.
02-16-2024 01:41 AM
Did you config Ip nhrp nhs whrn you config mGRE DMVPN?
Did you config ip nhrp map correctly?
MHM
02-16-2024 01:44 AM
NHRP config is done correctly. When I strip of the protection from the DMVPN tunnel, tunnel goes up and works as expected.
02-16-2024 01:50 AM
Are you use sharad keyword witg ipsec profile?
If yes remove it
MHM
02-16-2024 06:21 AM
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
02-16-2024 06:05 AM
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
02-21-2024 12:26 AM
02-21-2024 03:19 AM
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
02-21-2024 01:12 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide