Solved: IKEv2 Negotiation aborted due to ERROR: The peer's KE payload contained the wrong DH group

SMS Admin · ‎05-20-2017

Hello. On a site-to-site VPN that was working fine yesterday...

On our end there is a ASA5505. On the other end is a Fortinet appliance. As I said - the tunnel has been fine for months.

The other side moved their datacenter to a new location - same IPs, etc... basically jsut turning things off and back on but our tunnel isn't coming back up. (It shows in the ASDM monitor as connected but no traffic and this error in the logs:

IKEv2 Negotiation aborted due to ERROR: The peer's KE payload contained the wrong DH group

Any idea what may be going on? Thanks.

Rahul Govindan · ‎05-20-2017

If you are seeing the tunnel as established on the ASDM, then this error does not have any relevance. This error shows up during most Anyconnect connections to the ASA and can be ignored if this is not seen during the Fortinet's IKE negotiation. This is documented here:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtx35044/?referring_site=bugquickviewredir

Coming back to your problem, if your tunnel is established, you may want to check the output of "show crypto ipsec sa" on your ASA via CLI. This should show you if you are receiving encrypted traffic from the peer or not [Pkts encaps and decaps]

If your tunnel does not show up as established, the following debugs should give you more information:

debug crypto isakmp 127
debug crypto ipsec 127

View solution in original post

Rahul Govindan · ‎05-20-2017

If you are seeing the tunnel as established on the ASDM, then this error does not have any relevance. This error shows up during most Anyconnect connections to the ASA and can be ignored if this is not seen during the Fortinet's IKE negotiation. This is documented here:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtx35044/?referring_site=bugquickviewredir

Coming back to your problem, if your tunnel is established, you may want to check the output of "show crypto ipsec sa" on your ASA via CLI. This should show you if you are receiving encrypted traffic from the peer or not [Pkts encaps and decaps]

If your tunnel does not show up as established, the following debugs should give you more information:

debug crypto isakmp 127
debug crypto ipsec 127

SMS Admin · ‎05-20-2017

Thank you for the assistance. It turns out the other side made a slight change in the configuration. Once they restored from a backup, everything worked properly.

SimonKHickman · ‎02-20-2018

Greetings:

Just a FYI notification.

I noted the BUG has reference in particular to AnyConnect, I have observed the same error message on 9.6.(4)3 where the connecting client is Apple iOS11.2.6 native IKEv2 Always On.

There appears to be no affect to the client connectivity.

It does not occur during the initial negotiation.

From the logs it appears to be occurring after the idle timeout period.

Regards,

Simon.