FortiGate “no proposal chosen”: IKE, ESP and DH Checks

Confirm the tunnel selected by the request

Record the running builds, local interface/gateway, observed remote address, IKE version and intended tunnel at both ends. Use the version-matched IKE workflow linked below for one bounded negotiation. A NAT device may change the observed peer address. Do not publish the raw debug: it may include key material.

The official “No Proposal Chosen. Negotiate SA Error” KB shows that a gateway-address mismatch can produce this error. Therefore, verify tunnel selection before interpreting every occurrence as insufficient cryptography. Do not copy its sample secrets or addresses.

Compare only the transforms for the failed stage

AEAD proposals such as AES-GCM do not use a separate ESP integrity transform in the same way as an AES-CBC proposal. IKE still has its own PRF requirement. Keep the IKE SA and Child SA lists distinct; the phase 1 and phase 2 references describe different configuration scopes.

After an upgrade to FortiOS 7.6.5, inspect DH defaults

The 7.6.5 default-behavior release note states two different cases: new CLI defaults change from groups 14 and 5 to 20 and 21; on upgrade, tunnels using the former defaults are updated to 14, 20 and 21. Do not collapse these into a claim that every tunnel loses group 14.

Compare the actual post-upgrade phase 1 and phase 2 settings with the peer and the saved pre-upgrade configuration. A matching encryption name alone is insufficient. An explicitly configured tunnel and one inheriting defaults need not have identical results. The release note justifies checking this branch; it does not prove this is the cause of your failure.

Agree one compatible policy and verify rekey

Choose a mutually supported, approved proposal and applicable DH/PFS settings with the other administrator. Change only the identified mismatch in the existing tunnel during a coordinated window. Do not enable obsolete groups or every cipher to see what connects. If the remote peer cannot meet the required policy, plan its supported migration rather than silently weakening the gateway.

Record all old values at both ends. Verify the IKE SA and Child SA use the agreed transforms, then complete the intended application transaction. Observe a scheduled rekey when the failure occurs only after an initial successful connection; do not force global tunnel resets to accelerate that test.

Restore the exact prior tunnel settings if the coordinated change fails, while retaining an authorized recovery access path. A rollback must not become an unreviewed downgrade to a vulnerable firmware or weak crypto policy. Stop and clear the scoped IKE debug.

Start and stop version-specific IKE diagnostics · Compare IKEv2 transforms locally · Tunnel established but a subnet fails

A different error: “does not match configuration address”

If IKE reports a remote address that does not match the configured address, compare the actual packet source and the intended peer before changing proposals. The official address-mismatch KB distinguishes an address mistakenly owned locally by an interface/VIP/IP pool from a peer translated by upstream NAT. A third case is a VIP forwarding UDP 500/4500 away from the FortiGate’s own VPN service.

Inventory dependencies before correcting an address or VIP. Do not delete a production mapping merely because it uses the same ports: decide which service should own that destination and coordinate the change. Preserve its exact old configuration and verify both VPN negotiation and any intentionally published service after correction. A custom IKE port requires its own client/peer compatibility review; it is not a universal address-conflict fix.