Troubleshooting Tip: How to troubleshoot the message 'ike Negotiate ISAKMP SA Error' in the IKE debug log when proposals are the same on the VPN peers

[ojacinto]

Description	This article describes how to troubleshoot the message 'ike Negotiate ISAKMP SA Error no proposal chosen' when it appears in IKE debug logs.
Scope	FortiOS v6.4.0 and later, v7.0.0 and later, and v7.2.0 and later.
Solution	Upon running an IKE debug, the collected logs may show an error similar to the following: ike Negotiate ISAKMP SA Error: 2024-06-13 00:30:33.806824 ike 0:82a9c00faea20aca/0000000000000000:123: no SA proposal chosen, you need to validate the incoming proposal: 2024-06-13 00:32:22.050564 ike 0: comes 192.168.170.53:500->192.168.170.160:500,ifindex=3,vrf=0.... 2024-06-13 00:32:22.050596 ike 0: IKEv1 exchange=Aggressive id=efcc4ec0c1f63a13/0000000000000000 len=538 vrf=0 2024-06-13 00:32:22.050602 ike 0: in <address> 2024-06-13 00:32:22.050608 ike 0:efcc4ec0c1f63a13/0000000000000000:138: responder: aggressive mode get 1st message... 2024-06-13 00:32:22.050613 ike 0:efcc4ec0c1f63a13/0000000000000000:138: VID RFC 3947 4A131C81070358455C5728F20E95452F 2024-06-13 00:32:22.050616 ike 0:efcc4ec0c1f63a13/0000000000000000:138: VID draft-ietf-ipsec-nat-t-ike-03 7D9419A65310CA6F2C179D9215529D56 2024-06-13 00:32:22.050619 ike 0:efcc4ec0c1f63a13/0000000000000000:138: VID draft-ietf-ipsec-nat-t-ike-02 CD60464335DF21F87CFDB2FC68B6A448 2024-06-13 00:32:22.050621 ike 0:efcc4ec0c1f63a13/0000000000000000:138: VID draft-ietf-ipsec-nat-t-ike-02\n 90CB80913EBB696E086381B5EC427B1F 2024-06-13 00:32:22.050624 ike 0:efcc4ec0c1f63a13/0000000000000000:138: VID draft-ietf-ipsec-nat-t-ike-01 16F6CA16E4A4066D83821A0F0AEAA862 2024-06-13 00:32:22.050626 ike 0:efcc4ec0c1f63a13/0000000000000000:138: VID draft-ietf-ipsec-nat-t-ike-00 4485152D18B6BBCD0BE8A8469579DDCC 2024-06-13 00:32:22.050629 ike 0:efcc4ec0c1f63a13/0000000000000000:138: VID DPD AFCAD71368A1F1C96B8696FC77570100 2024-06-13 00:32:22.050644 ike 0:efcc4ec0c1f63a13/0000000000000000:138: VID FRAGMENTATION 4048B7D56EBCE88525E7DE7F00D6C2D3 2024-06-13 00:32:22.050651 ike 0:efcc4ec0c1f63a13/0000000000000000:138: VID FRAGMENTATION 4048B7D56EBCE88525E7DE7F00D6C2D3C0000000 2024-06-13 00:32:22.050654 ike 0:efcc4ec0c1f63a13/0000000000000000:138: VID FORTIGATE 8299031757A36082C6A621DE00000000 2024-06-13 00:32:22.050656 ike 0::138: received peer identifier FQDN 'Spokes' 2024-06-13 00:32:22.050663 ike 0: IKEv1 Aggressive, comes 192.168.170.53:500->192.168.170.160 3 2024-06-13 00:32:22.050679 ike 0:efcc4ec0c1f63a13/0000000000000000:138: incoming proposal: 2024-06-13 00:32:22.050682 ike 0:efcc4ec0c1f63a13/0000000000000000:138: proposal id = 0: 2024-06-13 00:32:22.050684 ike 0:efcc4ec0c1f63a13/0000000000000000:138: protocol id = ISAKMP: 2024-06-13 00:32:22.050685 ike 0:efcc4ec0c1f63a13/0000000000000000:138: trans_id = KEY_IKE. 2024-06-13 00:32:22.050687 ike 0:efcc4ec0c1f63a13/0000000000000000:138: encapsulation = IKE/none 2024-06-13 00:32:22.050688 ike 0:efcc4ec0c1f63a13/0000000000000000:138: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC, key-len=128 2024-06-13 00:32:22.050690 ike 0:efcc4ec0c1f63a13/0000000000000000:138: type=OAKLEY_HASH_ALG, val=SHA2_256. 2024-06-13 00:32:22.050701 ike 0:efcc4ec0c1f63a13/0000000000000000:138: type=AUTH_METHOD, val=PRESHARED_KEY. 2024-06-13 00:32:22.050703 ike 0:efcc4ec0c1f63a13/0000000000000000:138: type=OAKLEY_GROUP, val=MODP1536. 2024-06-13 00:32:22.050714 ike 0:efcc4ec0c1f63a13/0000000000000000:138: ISAKMP SA lifetime=86400 2024-06-13 00:32:22.050728 ike 0:efcc4ec0c1f63a13/0000000000000000:138: negotiation failure 2024-06-13 00:32:22.050764 ike Negotiate ISAKMP SA Error: 2024-06-13 00:32:22.050780 ike 0:efcc4ec0c1f63a13/0000000000000000:138: no SA proposal chosen Generally, it is possible to review the phase1 proposal (authentication and encryption algorithms), PSK and keylife time to match it between both peers. However, sometimes due to an error or a lack of knowledge of the IKE protocol, peers are configured to use a different IKE version. In this case, on the HUB side, the VPN tunnel phase1 is configured to use IKEv2: config vpn ipsec phase1-interface     edit "VPN_Spokes"       set type dynamic       set interface "port1"       set ike-version 2   <-       set peertype one       set net-device disable       set proposal aes128-sha256        set dpd on-idle       set dhgrp 5       set nattraversal forced       set peerid "Spokes"       set psksecret ENC ULaQp8jdf5EYJ       set dpd-retryinterval 60     next end While the spoke side is configured to use IKEv1: config vpn ipsec phase1-interface     edit "VPN_to_HUB"       set interface "port1"       set ike-version 1  <-       set mode aggressive       set peertype any       set net-device disable       set proposal aes128-sha256       set localid "Spokes"       set dhgrp 5       set nattraversal forced       set remote-gw 192.168.170.160       set psksecret ENC kuolnXfDzNUJbGL1BKSylXTO     next end As shown, even when the proposal and other parameters like PSK, DH group, peerid are matching on the phase1: when a negotiation request reaches the HUB side, the packet is dropped due to IKE version incompatibility. IKEv1 and IKEv2 are not compatible, which means a FortiGate using IKEv1 on the VPN phase1 will not be able to establish the tunnel with its peer that is trying to negotiate with IKEv2. The VPN logs show the message 'peer SA proposal not match local policy': To fix this error, use the same IKE version on both VPN peers. Note: From 7.4.2, if transport is set to 'TCP encapsulation' and FortiClient is not set up to use TCP (such as in an old FortiClient version not supporting TCP encapsulation), the same error can be observed. Switch back to 'Auto' and try to connect again.