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