cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
46628
Views
5
Helpful
3
Replies

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

SMS Admin
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

Rahul Govindan
VIP Alumni
VIP Alumni

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

3 Replies 3

Rahul Govindan
VIP Alumni
VIP Alumni

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

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.

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: