ASA 5525 Negotiation aborted ERROR Failed to compute the DH value

[bernard.goh]

My ASA 5525 recently encountered an issue where a previously established IKEV2 L2L tunnel suddenly became unable to establish any more with the error in the syslog indicating "Negotiation aborted due to ERROR: Failed to compute the DH value". I have tried clearing any inactive ipsec by using "clear ipsec sa inactive" and did a packet-tracer to try bringing the tunnel manually but no avail. Keep seeing the error. I did a reload and managed to bring the tunnel up. But in less than a day, the same problem happened again. The same tunnel refused to establish anymore. I can't keep reloading as it impact lots of other customer.

The version of the ASA is a bit old. Running at 8.6. 

Anyone has any clue? 

[balaji.bandi]

if this is running and all of sudden broken, as you mentioned there is no change your side, we need to know what changes other side ?

what device other side ? what DH value you using ? compare to other side ?

Troubleshoot tips :

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115935-asa-ikev2-debugs.html

[bernard.goh]

Hi Balaji,

   As mentioned, there is no change in configuration. The same tunnel for this customer was UP for more than a year. It suddenly happened yesterday. When I received the complain, I did a comparison on the configuration with the customer on line. They are the same. I read some other forum that a reload might bring it up. So, I did that and the tunnel indeed was UP. But, less than a day, it happened again. The DH is group 14. The other side is the same. The other end isn't a Cisco. Not sure which vendor.

[Rob Ingram]

@bernard.goh you say "But in less than a day, the same problem happened again" - sounds like the issue is re-keying after the lifetimes expire. Can you provide the full output of the errors.

Tbh I would upgrade to newer version such as 9.14, as numerous of bugs will be resolved from version 8.6

https://software.cisco.com/download/home/284143129/type/280775065/release/9.14.3%20Interim

[bernard.goh]

Hi Rob,

      I keep seeing the same error as following. (IP address removed)

Mar 7 05:24:04 MTTASA1 : %ASA-5-750001: Local:<my IP>:500 Remote:<peer IP>:500 Username:Unknown Received request to establish an IPsec tunnel; local traffic selector = Address Range: <my range> Protocol: 0 Port Range: 0-65535; remote traffic selector = Address Range: <customer range> Protocol: 0 Port Range: 0-65535
Mar 7 05:24:04 MTTASA1 : %ASA-4-750003: Local:<my IP>:500 Remote:<peer IP>:500 Username:Unknown Negotiation aborted due to ERROR: Failed to compute the DH value

    We know the version is old but we can't just upgrade the version as it is the production server with more than active 200 tunnels.

    Can only do that with the blessing from management. Normally take weeks if not months.

    Note : this tunnel failed at the phase 1. 

[Rob Ingram]

@bernard.goh is this error the final error message or does the exchange continue?

Probably not what you want to hear, you may want to consider raising a TAC call.....but they'll probably tell you to upgrade. Countless bugs resolved from version 8.6

[bernard.goh]

Rob,

   It is the final message and No more exchange after that.

   Yes, you are right that I did talked to the TAC and their suggestion was to upgrade it but it is the option now.

   They also suggested a reload which I did yesterday. The reload did bring it up but I can't keep doing that as it impacts other customers.

   So, I really hope to find out what had happened and how to resolve this issue without reloading ASA.

BG

[balaji.bandi]

I have seen some issue with others like checkpoint  The DH is group 14 having issue, also life time information. if we lower to DH 5 i it was stabled for Long, we need to know what is other side config.

Make sure you compare the config again both the side.

Note : ASA is a bit old. Running at 8.6.   - this code was end of Life more than decade now, also suggest to uplift to new version.

[bernard.goh]

Hi Balaji,

    The other side setting is as such:

set security vpn ipsec esp-group MTL_SMPP_ESP_PH2 lifetime 3600
set security vpn ipsec esp-group MTL_SMPP_ESP_PH2 mode tunnel
set security vpn ipsec esp-group MTL_SMPP_ESP_PH2 pfs dh-group14
set security vpn ipsec esp-group MTL_SMPP_ESP_PH2 proposal 1 encryption aes256
set security vpn ipsec esp-group MTL_SMPP_ESP_PH2 proposal 1 hash sha1
set security vpn ipsec ike-group MTL_SMPP_IKE_PH1 disable-strict-mode
set security vpn ipsec ike-group MTL_SMPP_IKE_PH1 ike-version 2
set security vpn ipsec ike-group MTL_SMPP_IKE_PH1 lifetime 28800
set security vpn ipsec ike-group MTL_SMPP_IKE_PH1 proposal 1 dh-group 14
set security vpn ipsec ike-group MTL_SMPP_IKE_PH1 proposal 1 encryption aes256
set security vpn ipsec ike-group MTL_SMPP_IKE_PH1 proposal 1 hash sha1
set security vpn ipsec site-to-site peer <my  IP> default-esp-group MTL_SMPP_ESP_PH2
set security vpn ipsec site-to-site peer <my  IP> ike-group MTL_SMPP_IKE_PH1
set security vpn ipsec site-to-site peer <my  IP> tunnel 1 esp-group MTL_SMPP_ESP_PH2

Our crypto setting is as such:

crypto ikev2 policy 220
encryption 3des
integrity sha
group 2
prf sha
lifetime seconds 86400

crypto map 3703_map 309 match address 399
crypto map 3703_map 309 set pfs group14
crypto map 3703_map 309 set peer <peer IP>
crypto map 3703_map 309 set ikev2 ipsec-proposal <customer name>
crypto map 3703_map 309 set security-association lifetime seconds 3600

BG

[bernard.goh]

Correction ...

My crypto setting is such 

crypto ikev2 policy 180
encryption aes-256
integrity sha
group 14
prf sha
lifetime seconds 28800

[balaji.bandi]

if this is correct configured, then i do not any issue , until we see full complete debug.

as we suggest to uplift the OS code to 9.X stable version.

[Sheraz.Salim · Accepted solution]

@bernard.goh i had a very similar issue with our firewall however, our firewall were 5545 and they were in HA pair. they were running software 9.8.X. The issue we encounter was every 12 to 16 hours our vpn performance were degrading on certain peer vpn tunnels with more than 300+ vpn tunnels and we were seeing the same log as you mentioned. TAC was involved but the fix we could not find as TAC argue was they want to see this issue when this happening in real time our argument was we willing to get in touch with TAC but we need a solution quickly, even though when the case was open with TAC we provided all the debug/tech support etc more than 2GIG of data. long story short at the end what we did was we have to introduce the more DH values in phase 1 on ikev2. this did fix the issue. 

example

crypto ikev2 policy 2
group 21 20 19 24 14 5

if you  have a Azure and AWS tunnel than bring their DH values forward.

hope this will help you.