Main Mode Failed to match proposal:.... Wrong value for: Authentication Method

[Dilian_Chernev]

Hi mates,

We have an issue with RA users establishing VPN to GW and what I found in logs this:

Main Mode Failed to match proposal: Transform: AES-256, SHA1, Pre-shared secret, Group 2 (1024 bit); Reason: Wrong value for: Authentication Method

After some investigation, I found out that IPSEC VPN default certificate of the GW was expired.
Renew the certificate, installed policy and RA users were able to login again.

Just wanted to leave this info here, in case someone has the same issue. 
There is no useful information in knowledge base about it.

Thanks,

Dilian

[_Val_]

Thanks for sharing

[the_rock]

Great info. Not logically obvious that would be an issue based on the error.

[K_R_V]

We also encountered this issue with the exact same error but our VPN certificate was still valid. We managed to find the exact timing it  all started and rolled back the only change we did to solve the issue.

The change : we added a static NAT rule on the public IP address on port 2222 to an internal server on port 22. This was done for 1 single public IP address. Not sure why this caused an issue.

Quantum Spark, version R81.10.07 , cloud management on R81.20.

[zsigmondrichard]

We are facing this issue as well. Currently, we are on R80.40 Take 139 and it is working fine for the RA clients. As soon as we are installing any higher JHA to the gateways, RA clients can connect for like 5 minutes, and after this new logins start to fail due to this issue. We can see this error message in the vpnd.elg after a VPN debug. 

Users are using Endpoint Security VPN to connect. On the client side, they get "Connection Failed. IKE Negotiation with the gateway has failed. Make sure the user is properly defined on the firewall" message. We tried to solve it based on sk103269 but it starts to fail again after 5 minutes.

VPN certificate is 3rd party, but valid.

Until now, we can solve it only by a rollback to R80.40 Take 139. This is the last take RA connection is working for us. We had TAC cases for the issue, but unfortunately, we don't have the root cause...

[the_rock]

You mean, this is an error you see?

Main Mode Failed to match proposal: Transform: AES-256, SHA1, Pre-shared secret, Group 2 (1024 bit); Reason: Wrong value for: Authentication Method

[zsigmondrichard]

Hi!

Yes, this message can be seen in the vpnd.elg

chooseProposalFromList: Failed to match proposal. Transform: AES-256, SHA1, Group 2 (1024 bit); Reason: Wrong value for: Authentication Method
chooseProposalFromList: Failed to match in strict mode. Will try matching all supported DH groups

In order to solve this, we tried following sk103269. After doing the steps, it worked again for like 5 minutes and a new error message appeared on the client side: "Connection Failed. Could not agree on common methods. Check that the user is properly  defined"...

sk170515 describe a solution for the previous error message, we followed the steps, and worked again for 5 minutes and it showed the first error message again "Connection Failed. IKE Negotiation with the gateway has failed. Make sure the user is properly defined on the firewall".

At this time we had to roll back to Take 139. We tried to install Take 161 and Take 173 but the same errors appeared. Management server is not a problem, it is on Take 173. The issue is only with the gateways. As Take 198 just came out, we will wait until GA and give it a try...

Best Regards,

Richard

[the_rock]

Hey Richard,

We had similar issues with customer about 3 years ago and changed bunch of those global properties options and nothing worked. I have no clue how it got solved at the end, but one day it all just worked without any new changes made. I would have to "comb" through my emails to double check, but its possible something may had been corrected on the gateway side.

[the_rock]

K, was able to find the case that went to escalation team in Ottawa back in May 2021 and it seems that bunch of people ended up installing updated vpn client at that time and it started working. Some users had issues afterwards, but after few days, all was fine.

[zsigmondrichard]

Hi!

Thanks for the information!

Last time at Take 173 we tried with a newly installed VPN client and didn't work, but it was more than a half year ago so we will try it again.

In our TAC cases that were opened for this issue, TAC was trying to point to some general IPsec/NAT issues as a root cause. Based on Kristof's comment, NAT can be a place that we need to check. But I believe if some general issue would be the root cause, it wouldn't work fine with Take 139. I mean, without any manual configuration change, RA connection starts to fail. One thing changed, the installed hotfix Take.

Best Regards,

Richard

[the_rock]

I hate to be negative, but Im always 100% realistic. At the end of the day, for these issues, its never easy to figure out the solution. Might take lots of testing and degugs, for sure. In case you need it, below are debugs TAC always gives to customers.

Cheers,

Andy

1) Logs from client machine.
2) Wireshark Capture on that client machine.
3) on the firewall side, we need to enable vpn debug, pdpd and pepd debug, and CPND debug.
Start vpn debug:
[Expert@HostName]# vpn debug trunc ALL=5
[Expert@HostName]# ike debug trunc ALL=5 (if running R81.10 or higher)

-replicate the issue

Stop vpn debug:
[Expert@HostName]# vpn debug off
[Expert@HostName]# vpn debug truncoff
[Expert@HostName]# ike debug off (if running R81.10 or higher)
[Expert@HostName]# ike debug truncoff (if running R81.10 or higher)

Please collect the following files:
cd $FWDIR/log
$FWDIR/log/ike.elg*
$FWDIR/log/ikev2.xmll*
$FWDIR/log/vpnd.elg*
$FWDIR/log/iked_debug.elg* (if running R81.10 or higher)
$FWDIR/log/legacy_ike.elg (if running R81.10 or higher)