|
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.
Another reason could be to ike version mismatch. Refer to this article. Troubleshooting Tip: How to troubleshoot the message 'ike Negotiate ISAKMP SA Error' in the IKE debu...
Possible causes of 'no proposal chosen':
- Verify whether the remote gateway IP is configured correctly or not.
- network-id configured on both peers: it has to match.
-
network-id is not configured/enabled on the other peer (on one peer).
-
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.
-
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
-
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
7. Both peers are running ikev2, but there is a mismatch in the encryption and authentication algorithm chosen.
ike 0:VPN:968190: sent IKE msg (SA_INIT): 10.10.10.11:500->192.168.10.11:500, len=240, vrf=0, id=fa9f847249edb233/0000000000000000
ike 0: comes 192.168.10.11:500->10.10.10.11:500,ifindex=7,vrf=0....
ike 0: IKEv2 exchange=SA_INIT_RESPONSE id=fa9f847249edb233/0000000000000000 len=36
ike 0: in FA9F847249EDB2330000000000000000292022200000000000000024000000080000000E
ike 0:VPN:968190: initiator received SA_INIT response
ike 0:VPN:968190: processing notify type NO_PROPOSAL_CHOSEN
ike 0:VPN:968190: malformed message
ike shrank heap by 159744 bytes
ike 0:VPN:968190: negotiation timeout, deleting
ike 0:VPN: connection expiring due to phase1 down
ike 0:VPN: deleting
ike 0:VPN: deleted
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.
|
