# IKEv2, WR21 to Cisco IOS \[SOLVED\] **URL:** \ **Category:** Digi TransPort WR (Series)\ **Tags:** wr21, cisco, ipsec, ikev2, ios\ **Created:** [October 14, 2020, 8:13pm UTC](https://forums.digi.com/t/ikev2-wr21-to-cisco-ios-solved/21892 "2020-10-14T20:13:44Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![jserink](https://avatars.discourse-cdn.com/v4/letter/j/bc79bd/32.png) [@jserink](https://forums.digi.com/u/jserink)\ **Post date:** [October 14, 2020, 8:13pm UTC](https://forums.digi.com/t/ikev2-wr21-to-cisco-ios-solved/21892/1 "2020-10-14T20:13:44Z")
Hello: I have a strange problem that I am only seeing in India. I have not been able to duplicate this behavior in Singapore, however; in India it occurs with all the cell phone providers: At the Digi WR21 initiator end the event log looks like this: 06:39:12, 15 Oct 2020,(1683) IKEv2 Negotiation completed pe,Initiator 06:39:12, 15 Oct 2020,(1683) IKE Negotiation Failed. Peer: ,Retries Exceeded 06:39:12, 15 Oct 2020,(1687) IKE Keys Negotiated. Peer: A.B.C.D 06:39:11, 15 Oct 2020,(1687) IKE Notification: NATD dest. IP,RX 06:39:11, 15 Oct 2020,(1687) IKE Notification: NATD source IP,RX 06:39:11, 15 Oct 2020,(1687) New IKEv2 Negotiation peer A.B.C.D,Initiator (Init) 06:39:11, 15 Oct 2020,IKE Request Received From Eroute 0 06:39:02, 15 Oct 2020,(1682) IKEv2 Negotiation completed pe,Initiator 06:39:02, 15 Oct 2020,(1682) IKE Negotiation Failed. Peer: ,Retries Exceeded 06:39:02, 15 Oct 2020,(1686) IKE Keys Negotiated. Peer: A.B.C.D 06:39:01, 15 Oct 2020,(1686) IKE Notification: NATD dest. IP,RX 06:39:01, 15 Oct 2020,(1686) IKE Notification: NATD source IP,RX 06:39:01, 15 Oct 2020,(1686) New IKEv2 Negotiation peer A.B.C.D,Initiator (Init) And if you check, there are no IPSec or IKEv2 SAs. But on the Cisco side, it looks like this: Interface: GigabitEthernet0/0/0 Profile: SOIprofile Session status: UP-ACTIVE Peer: 106.215.173.255 port 64866 Session ID: 23693 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Inactive Session ID: 23689 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Inactive Session ID: 23687 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Inactive Session ID: 23685 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Inactive Session ID: 23688 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Inactive Session ID: 23684 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Inactive Session ID: 23691 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Inactive Session ID: 23686 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Inactive Session ID: 23683 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Inactive Session ID: 23692 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Inactive Session ID: 23694 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Inactive Session ID: 23695 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Active Session ID: 23690 IKEv2 SA: local A.B.C.D/4500 remote 106.215.173.255/64866 Inactive IPSEC FLOW: permit ip host 1.1.1.10 host 2.2.2.3 Active SAs: 2, origin: dynamic crypto map The Cisco is convinced that it has negotiated a valid IKEV2 session, and the debugs confirm that, and the IPSec comes up, debugs confirm that. But nothing at the Digi end. So the Digi send another request, the Cisco listens, generates another SA and this fills up until the inactive SAs start to timeout and fall off. This behavior happens only about 10% of the time. I have tried clearing the crypto sessions on the cisco side, clearing the ikev2 SAs on the cisco side but the only solution we’ve found is to reboot the Digi. Sometimes we have to reboot 3-4 times to get it to come right. We see this only with the GPRS. If we connect the WR21 in port isolate mode through an ISP supplied ADSL router, that link never does this. This is very odd. Has anyone seen this before? Any work arounds? Cheers, John ---
**Author:** ![jserink](https://avatars.discourse-cdn.com/v4/letter/j/bc79bd/32.png) [@jserink](https://forums.digi.com/u/jserink)\ **Post date:** [October 17, 2020, 3:31am UTC](https://forums.digi.com/t/ikev2-wr21-to-cisco-ios-solved/21892/2 "2020-10-17T03:31:05Z")
ok guys… I’m not going to pop the champagne just yet but… 3 days ago I put i this statement into the Cisco in general config mode: crypto ikev2 fragmentation I haven’t seen the round-robin IKEv2 negotiation confusion since. If I go another 2 days without seeing it, I’ll consider it solved. Cheers, john ---
**Author:** ![jserink](https://avatars.discourse-cdn.com/v4/letter/j/bc79bd/32.png) [@jserink](https://forums.digi.com/u/jserink)\ **Post date:** [October 20, 2020, 1:03am UTC](https://forums.digi.com/t/ikev2-wr21-to-cisco-ios-solved/21892/3 "2020-10-20T01:03:13Z")
It has been 7 days since this fix was put in and problem has not reoccurred so I’m calling this fixed. Cheers, john