IKEv2 connections problems

[jorgemfm]

Hi,

Note: I'm kind of new to cisco, and this configuration was not made by me.

We have a IKEv2 tunnel configured and I rebember that when I run 

show crypto ikev2 sa

 it would only show 1 Tunnel with status READY

A few week ago I noticed that now it shows 2 tunnels, one with READY status a onother with IN-NEG status.

Router#show crypto ikev2 sa
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
2         x.x.x.x/500          x.x.x.x/500    none/none            IN-NEG
      Encr: 3DES, Hash: SHA96, DH Grp:2, Auth sign: Unknown - 0, Auth verify: Unknown - 0
      Life/Active Time: 120/0 sec

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         x.x.x.x/500          x.x.x.x/500    none/none            READY
      Encr: 3DES, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/693 sec

 IPv6 Crypto IKEv2  SA

I didn't make any change, I don't know if the other part has made any, buy is there any way I can understand what is wrong?

Also, we started having problems with the connection, from time to time users where unable to acess the remote network and I have to run clear comand so that thay can again connect.

clear crypto ikev2 sa

Any ideas on how I can start investigating this?

Thank you!

[MHM Cisco World]

Yes that enough, 
try 
1-make PSK same for local and remote
2-check the remote ID and local ID if there are any NAT between two router and you use mapped not real IP.

[fgafurov29]

I have the same situation

in the profile  Lifetime is set to 86400

and on cryptomap also 86400

Local 10.10.10.10 - cisco 2911

Remote 20.20.20.20 - ASA

Tunnel-id Local                 Remote                fvrf/ivrf            Status

3         10.10.10.10/500      20.20.20.20/500    none/none            IN-NEG

      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:14, Auth sign: Unknown - 0, Auth verify: Unknown - 0

      Life/Active Time: 120/0 sec

IKEv2 profile: PROFILE_CBT

 Ref Count: 2

 Match criteria:

  Fvrf: global

  Local address/interface: none

  Identities:

   address 20.20.20.20 255.255.255.255

  Certificate maps: none

 Local identity: none

 Remote identity: none

 Local authentication method: pre-share

 Remote authentication method(s): pre-share

 EAP options: none

 Keyring: CBT

 Trustpoint(s): none

 Lifetime: 86400 seconds

 DPD: disabled

 NAT-keepalive: disabled

 Ivrf: none

 Virtual-template: none

 mode auto: none

 AAA AnyConnect EAP authentication mlist: none

 AAA EAP authentication mlist: none

 AAA Accounting: none

 AAA group authorization: none

 AAA user authorization: none

crypto map IPSECMAP 100 ipsec-isakmp

 set peer 20.20.20.20

 set security-association lifetime seconds 86400

 set transform-set CBT

 set pfs group14

 set ikev2-profile CBT

 match address VPN_CBT

[MHM Cisco World]

useful post DH group mismatch.
https://community.cisco.com/t5/network-security/dh-group24-phase-i-and-set-pfs-group24-phase-ii/m-p/4604135#M1089792

[jorgemfm]

Hi Again

Thank all for all the replies.

Everything is currently working now, but I really can't tell you what cause the problem...we made some changes, that didnt work, than later on it just randomly started working.

After it was working on our local network, users from VPN access where not able to access the tunnel, then later like magic it just started to work...

We have change also our ISP router, I don't know if that helped or not, but we where on this several days trying diferent configs and doing debug to a point that I really don't know what happened.

If any one whants to look at some configuration parameter please just ask.

Thank you

[MHM Cisco World]

Sure I need to see last config if you can share, 
also the show crypto ipsec sa and show crypto isakmp sa.

[tommar]

its very often the transport network thats different to and from the remote endpoint, thats causing delays and can be dropped for any reason on the remote carriers network between your endpoints. no debugs will tell you this.