Description
This article describes the case when using a configured site-to-site IPSec tunnel between FortiGate and Azure. The tunnel has phase1 as well as phase2 up, but still getting the error 'No proposal chosen'.
Scope
FortiGate.
Solution
Run the below debug to troubleshoot the IPSec tunnel issue:
diagnose debug reset
diagnose vpn ike log-filter dst-addr4 x.x.x.x <- WAN IP of the remote side.
diagnose debug application ike -1
diagnose debug enable
To disable the debug: diagnose debug disable.
Note: Starting from v7.4.1, the 'diagnose vpn ike log-filter dst-addr4' command has been changed to 'diagnose vpn ike log filter rem-addr4'.
For the IPSec tunnel between FortiGate and Azure, debugs show the error ‘no proposal chosen’ even if phase1 and phase2 are up.
In this case, the DH group can cause issues.
Azure side is using DH group as ECP256, on the FortiGate side, it matches with DH group 19: About cryptographic requirements and Azure VPN gateways.
Change the DH group to 2 on both FortiGate as well as Azure for phase1 configuration of the tunnel and disable PFS for phase2 configuration.
Try to run the debug command again and check if that helped.
If the Azure side is the default Azure VPN gateway instead of the FortiGate VM, the default Encryption for Phase 2 is 'GCMAES256', which could differ from the FortiGate setting. Make sure it is identical on both sides.
Default IPsec on Azure Native gateway
In case Azure side is using 'GCMAES128' Encryption for Phase 2, need to set proposal 'aes128gcm' in FortiGate phase 2 encryption to match. Flush the tunnel, once the negotiation is done, traffic should start passing.
If issues are still experienced, contact the TAC team.
