01The one rule: a proposal is an AND

A "proposal" (or transform set) is a bundle of parameters offered as a single unit. The other peer accepts it only if it holds an identical bundle — every attribute matching at once. Matching encryption isn't enough if the DH group differs; the whole set has to line up. That's why "but AES-256 is set on both sides!" doesn't help on its own.

Phase-1 match = encryption & integrity & DH-group & auth-method & IKE-version — all must agree

The upside: you don't need the whole list to match, just one complete bundle in common. Offer AES256-SHA256-DH14 on both ends and the tunnel forms even if every other proposed line differs.

02Which phase failed?

Fix the right phase and you're halfway done. The status tells you where it stopped:

  • Phase 1 (IKE SA) builds the secure channel between the gateways. If it fails, nothing comes up — no IKE SA at all.
  • Phase 2 (IPsec / child SA) builds the SAs that actually carry your traffic. Its tell-tale: Phase 1 is up but no data flows and there are no Phase 2 SAs.
get vpn ipsec tunnel summary          # up/down + rx/tx per tunnel at a glance
diagnose vpn ike gateway list         # Phase 1: is there an established IKE SA for this peer?
diagnose vpn tunnel list              # Phase 2: are there child SAs, with which enc/auth/selectors?
gateway 'HQ-to-Branch'  status: established     <- Phase 1 OK …
name=HQ-to-Branch  ... npkts=0  ... no SA         <- … but no Phase 2 SA → look at Phase 2 attributes
# If 'diagnose vpn ike gateway list' shows no/half-open SA instead → it's a Phase 1 problem.

03The attributes that must match

Phase 1 — the channel between gateways:

EncryptionAES128 / AES256 / (3DES) — must match.
Authentication / integritySHA256 / SHA1 / (MD5) — must match. (AES-GCM bundles this in.)
DH group14 / 19 / 20 / 21 … — must match. The single most common culprit.
IKE version & modeIKEv1 (main/aggressive) vs IKEv2 — must match; v1↔v2 never negotiate.
Auth method + PSK/certSame method, and the same PSK (a PSK mismatch is a separate auth failure, not a proposal one — see §06).
Key lifetimeNegotiated, not matched — usually does not block the tunnel (see §06).

Phase 2 — the SA that carries traffic:

Encryption + integrity (ESP)Must match (e.g. AES256/SHA256, or AES-GCM).
PFS + its DH groupBoth ends PFS on and same group, or both off. A one-sided PFS is a classic Phase 2 killer.
Traffic selectors (proxy-IDs)Local/remote subnets must mirror across the peers (your local = their remote).
Lifetime (sec / KB)Negotiated (lower wins); a mismatch causes rekey churn, not a hard failure.

04Prove it: read the IKE debug

The IKE debug names the failure in plain words. Filter to the one peer, then re-trigger the tunnel:

diagnose debug reset
diagnose vpn ike log filter clear
diagnose vpn ike log filter rem-addr4 203.0.113.2     # focus on this peer only
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable
diagnose vpn ike gateway flush name "HQ-to-Branch"    # re-negotiate now
# … watch the exchange, then: diagnose debug disable ; diagnose debug reset
# Phase 1 mismatch:
ike 0:HQ-to-Branch: responder received SA_INIT msg
ike 0:HQ-to-Branch: negotiation failure
ike 0:HQ-to-Branch: no SA proposal chosen          <- Phase 1 attributes don't line up

# Phase 2 mismatch (Phase 1 was fine):
ike 0:HQ-to-Branch: no matching IPsec SA / selectors
ike 0:HQ-to-Branch: no SA proposal chosen (quick mode)   <- fix Phase 2 / proxy-IDs

"no SA proposal chosen" (IKEv1) or "NO_PROPOSAL_CHOSEN" (IKEv2) is the signature of a mismatch. Where it appears — SA_INIT/main mode vs quick mode — tells you Phase 1 vs Phase 2.

05Compare both sides fast

The fastest fix is a side-by-side. Dump each peer's config and fill one worksheet — the odd cell out is your answer. 

show vpn ipsec phase1-interface       # Phase 1: proposal, dhgrp, ike-version, keylife
show vpn ipsec phase2-interface       # Phase 2: proposal, pfs/dhgrp, src/dst-subnet, keylifeseconds
      Attribute        Local (HQ)         Remote (Branch)     match?
      ----------------------------------------------------------------
P1    encryption       aes256             aes256              ✔
P1    integrity        sha256             sha256              ✔
P1    dhgrp            14                 5                   ✘  ← fix this
P1    ike-version      2                  2                   ✔
P2    pfs / dhgrp      enable / 14        disable             ✘  ← and this

06The usual suspects (incl. the lifetime myth)

  • DH group. Encryption and auth match, but the groups differ (14 vs 5, or 19/20 vs 14). Number one cause of a Phase 1 that "should" work.
  • One-sided PFS. Phase 2 PFS enabled on one peer only, or the same PFS with different groups — Phase 1 up, Phase 2 fails.
  • Traffic selectors / proxy-IDs. Subnets not mirrored (or a policy-based peer talking to a route-based one) → "no matching selectors" even with perfect crypto.
  • IKE version / mode. IKEv1 on one side, IKEv2 on the other — they never speak; or main vs aggressive in IKEv1.
  • PSK mismatch. Not technically a proposal mismatch — it fails authentication after the proposal is accepted, with a different error ("probable pre-shared key mismatch"). Rule it in/out separately.
  • The lifetime "mismatch" myth. Key lifetime is negotiated, not matched: each peer proposes its own and the lower value is used, so a difference alone usually does not stop the tunnel forming. What it does cause is rekey churn — periodic renegotiation or brief drops if the two ends disagree wildly, or a mismatch between seconds-based and traffic (KB) based lifetimes. Align them to stop the flapping, but don't chase lifetime for a tunnel that never comes up at all — that's encryption/auth/DH.

07Fix & verify

  • Make one complete bundle common to both peers (same encryption + integrity + DH, same IKE version; for Phase 2 add matching PFS and mirrored selectors).
  • Re-trigger and confirm both phases:
diagnose vpn ike gateway flush name "HQ-to-Branch"    # renegotiate with the corrected config
diagnose vpn ike gateway list                         # Phase 1 → 'established'
diagnose vpn tunnel list                              # Phase 2 → SA present, npkts increasing
gateway 'HQ-to-Branch'  ike v2  status: established
name=HQ-to-Branch  proto=ESP  enc=aes256  auth=sha256  npkts=124  <- traffic flowing

Then remember the boring last mile: a firewall policy permitting tunnel traffic both ways, and a route sending the remote subnet at the IPsec interface (covered in the FortiGate firewall playbook §06).

08References