Technical Tip: FortiClient VPN authentication fails on first attempt with “No SA proposal chosen” but succeeds on second attempt

[edyrmishi]

Description	This article describes an issue where a FortiClient IKEv2 remote-access connection fails on the first authentication attempt with the error 'No SA proposal chosen' but establishes successfully on the second attempt. This behavior typically occurs when there is a mismatch in the transport protocol settings between the FortiClient and the FortiGate Phase 1 configuration.
Scope	FortiGate, FortiClient, FortiClient EMS.
Solution	Symptoms: Users may experience the following behavior when attempting to connect to the VPN: The first connection attempt fails. The error message 'No SA proposal chosen' is displayed in the IKE debug log output. When credentials are re-entered immediately, the second connection attempt succeeds. This behavior is consistent across both internal and external browsers. Analyzing the IKE debug logs reveals a mismatch in the transport protocol negotiation during the initial connection attempt. FortiClient Behavior: The FortiClient is configured with transport_mode set to Auto (UDP with fallback to TCP). By default, it initiates the connection using UDP (typically port 500/4500). FortiGate Configuration: The Phase 1 interface on the FortiGate is explicitly configured to use TCP only. config vpn ipsec phase1-interface     edit "VPN-Tunnel"         set type dynamic         set interface "wan1"         set ike-version 2         set peertype any         set net-device disable         set proposal aes256-sha256         set transport tcp         set dpd on-idle     next end The Conflict: During the first connection attempt, FortiClient follows its default behavior and initiates the IKE negotiation over UDP. Because the FortiGate only allows TCP, it rejects the proposal, resulting in the 'No SA proposal chosen' error. On the second attempt, FortiClient falls back to TCP, at which point the FortiGate accepts the connection and the tunnel is established successfully. This explains why authentication consistently fails on the first attempt but succeeds on the second. To resolve this issue, both sides need to use matching transport settings. In this scenario, one of the following options must be selected: Option 1: FortiClient EMS Configuration update. The transport protocol on the FortiClient EMS profile needs to be configured to use TCP only. This forces the client to use TCP immediately, eliminating the initial UDP failure. EMS XML Configuration example: In the endpoint profile XML, the <transport_mode> value needs to be changed to 1 (TCP): <vpn> <options> ... </options> <ipsecvpn> <connections> <connection> <name>VPN_Name</name> <type>manual</type> <ike_settings> <transport_mode>1</transport_mode> ... </ike_settings> </connection> </connections> </ipsecvpn> </vpn> Option 2: FortiGate Phase 1 Configuration update. The 'udp-fallback-tcp' option should be enabled in the Phase 1 configuration on the FortiGate. This allows the FortiGate to accept the initial UDP attempt while maintaining the ability to fallback to TCP. config vpn ipsec phase1-interface     edit "VPN-Tunnel"         set transport udp-fallback-tcp     next end