FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
fwilliams
Staff
Staff
Article Id 243552
Description This article describes how to troubleshoot the message 'no proposal chosen' and 'no SA proposal chosen' when they appear in IKE debug logs.
Scope FortiGate.
Solution

When logs collected with 'ike -1' contain 'no proposal chosen' for example, it can be due to any of below:

 

Debug commands:

 

diagnose debug application ike -1

diagnose debug enable

 

Caution:

Note that the error message 'no proposal chosen' differs from 'no SA proposal chosen'. The latter ('no SA proposal chosen') is usually due to a mismatch in the phase 1 configuration such as IKE mode (Aggressive/Main) and Encryption/Authentication algorithms. To resolve the issue, make sure the IKE mode and Phase 1 Proposal match on both sides. 

 

fwilliams_0-1674390417285.png

 

Possible causes of 'no proposal chosen':

 

fwilliams_1-1674390439830.png

 

  1. Verify whether the remote gateway IP is configured correctly or not.
  2. network-id configured on both peers: it has to match.

 

fwilliams_2-1674390463656.png

 

  1. network-id is not configured/enabled on the other peer (on one peer).

     

  2. The peers are running different IKE versions (one is on ikev1 and the other on ikev2). It does not matter, even if the encrypt/auth algorithm matches.

     

    fwilliams_3-1674390491896.png

     

     

  3. Specify the Local ID at the IPSec VPN Tunnel Phase 1:

     

 

config vpn ipsec phase1-interface

    edit "VPN_Tunnel_name"

        set localid-type address

        set localid <IP_address of outgoing interface>

end

 

Note

If the name of the Tunnel contains spaces, replace them with a backslash (\). For instance, if the VPN tunnel is named VPN to HUB.

When modifying in the CLI:

 

config vpn ipsec phase1-interface

(phase1-interface) # edit VPN\ to\ HUB

 

  1. Disable the Perfect Forward Secrecy (PFS) at the IPSec VPN Tunnel Phase 2. 

     

 

config vpn ipsec phase2-interface

    edit "VPN_Tunnel_name"

        set pfs disable

end

 

In a Hub-Spoke or site-to-site topology if the PFS is enabled on the hub side or remote site, make sure it is enabled on the spoke or local site as well, or it will give this error 'No Proposal Chosen' when doing the IKE debugs on the spoke side

 

To verify the proposal below command:


diagnose vpn ike gateway list

vd: root/0
name: krpton
version: 1
interface: port2 4
addr: 10.5.146.11:500 -> 10.5.136.56:500
tun_id: 10.5.136.56/::10.5.136.56
remote_location: 0.0.0.0
network-id: 0
transport: UDP
created: 84594s ago
peer-id: 10.5.136.56
peer-id-auth: no
pending-queue: 0
IKE SA: created 1/3 established 1/3 time 0/6/10 ms
IPsec SA: created 0/2 established 0/1 time 0/0/0 ms

id/spi: 52 4dc149c62eac4ff4/77a8e531e508a031
direction: responder
status: established 6501-6501s ago = 0ms
proposal: aes128-sha256                 <----
key: 435d55bdb95b4796-2426203a826f2057
QKD: no
lifetime/rekey: 86400/79628
DPD sent/recv: 00000000/00000000
peer-id: 10.5.136.56

 

No proposal was chosen error on the HUB and spoke setup.

 

Configuration:

 

HUB:

 

config vpn ipsec phase1-interface
    edit "COPP-WAN2"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device disable
        set mode-cfg enable
        set proposal aes256-sha256
        set add-route disable
        set dpd on-idle
        set comments "VPN: COPP-WAN2 [Created by IPSEC Template]"
        set npu-offload disable
        set network-overlay enable
        set network-id 203
        set ipv4-start-ip 192.168.203.10
        set ipv4-end-ip 192.168.203.250
        set ipv4-netmask 255.255.255.0
        set psksecret ENC 8bQ397W7b23yoWM/9VorW/

        9YoSwBsrv9oclF+F3EE8P6+8TnCmS6hY8G7iecX0FEs1ethBALvcCvreDpc/Gsp

        xffOFUqsyV6nrIP4qZRmG2PuokmHPNtyajAZir8d1RjIbAJQI9iQqyweJT

        cuPS3miE7QuqrJq7gDVjeS/bU5CAqZDAPUR0AxwnwED/NJ1**bleep**PYE7Q==
        set dpd-retryinterval 60
    next
end

 

Spoke:

 

    edit "COPP-WAN2"
        set interface "lan2"
        set ike-version 2
        set peertype any
        set net-device enable
        set mode-cfg enable
        set proposal aes256-sha256
        set add-route disable

        set network-overlay enable    <----
        set network-id 203        <----
        set remote-gw 2.2.2.2
        set psksecret ENC JRLMxnJWDJkBeO0vEHx7SSP0UxUhDb41ErzMCBbgfoVc9cKgwXe6h39Fe

        HYWTZcrPEQUgO8RHx2oY8UJsGWpdWnXTNfO29QgBVk6wJ6TxTIBeRHH+t4sShpmhOBDNbp6qT/   

        YJgkCKR3k8MCdHOf0zpxehsJjFOaxVRxe7r+newiqabDnqiqWInbdIzJloSUW6FoB0g==
        set dpd-retryinterval 60
    next
end

 

On the SPOKE side, network ID and overlay should be enabled to match with HUB.

 

Note:

This error can occur when one of the sites has DDNS as a 'Remote Gateway' in the IPsec phase1 configuration.

This happens when the DDNS Url resolution does not match the actual IP of the remote site and it has nothing

to do with phase1 proposals.

For version 7.4.5 and above:


IKE negotiations between FortiGate and another vendor device may fail with the error 'no proposal found' in IKE debugs after upgrading to v7.4.5 or above.

2025-01-13 17:15:02.454729 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: responder: main mode get 1st message...
2025-01-13 17:15:02.454742 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: VID DPD AFCAD71368A1F1C96B8696FC77570100
2025-01-13 17:15:02.454754 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: VID unknown (16): 27BAB5DC01EA0760EA4E3190AC27C0D0
2025-01-13 17:15:02.454765 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: VID unknown (16): 6105C422E76847E43F9684801292AECD
2025-01-13 17:15:02.454775 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: VID draft-ietf-ipsec-nat-t-ike-00 4485152D18B6BBCD0BE8A8469579DDCC
2025-01-13 17:15:02.454785 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: VID draft-ietf-ipsec-nat-t-ike-02 CD60464335DF21F87CFDB2FC68B6A448
2025-01-13 17:15:02.454799 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: VID draft-ietf-ipsec-nat-t-ike-02\n 90CB80913EBB696E086381B5EC427B1F
2025-01-13 17:15:02.454810 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: VID draft-ietf-ipsec-nat-t-ike-03 7D9419A65310CA6F2C179D9215529D56
2025-01-13 17:15:02.454820 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: VID RFC 3947 4A131C81070358455C5728F20E95452F
2025-01-13 17:15:02.454833 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: VID unknown (28): 699369228741C6D4CA094C93E242C9DE19E7B7C60000000500000500
2025-01-13 17:15:02.454844 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: VID draft-ietf-ipsra-isakmp-xauth-06.txt 09002689DFD6B712
2025-01-13 17:15:02.454854 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: VID unknown (20): FD808804DF73B15150709D878044CDE0AC1EFCDE
2025-01-13 17:15:02.454866 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: no proposal found 
2025-01-13 17:15:02.454876 ike V=root:0:6c0b2db8c4305686/0000000000000000:4357875: no SA proposal chosen

 

In this case, the Wireshark capture will show the proposals correctly. However, the FortiGate 'iked' will ignore the proposal payload due to the value of SPI size. From v7.4.5 onwards, FortiGate requires the SPI size of the IKE SA proposal to be zero. If this value is non-zero, the proposal will be ignored.

In Wireshark, the proposal payload will look like this:

Payload: Proposal (2) # 1
Next payload: NONE / No Next Payload (0)
Reserved: 00
Payload length: 56
Proposal number: 1
Protocol ID: ISAKMP (1)
SPI Size: 8
Proposal transforms: 1
SPI: 2a64aae3d0020b86
 

Workaround: Set up FortiGate as the initiator in IKE negotiations.