Site-to-Site VPN (Nebula SD-VPN, Hub-and-Spoke) — "No proposal chosen"

sebala · August 31

Environment

Nebula Hub-and-Spoke SD-VPN. Hub = HQ, Spoke = one store.
Hub: USG FLEX 200, V5.42(ABUI.1), MAC D8:EC:E5:78:60:AB, public IP 82.66.18.xxx.
Spoke: USG FLEX 200, V5.42(ABUI.1), MAC FC:22:F4:F6:C1:59, public IP 82.127.155.xxx.
Both "Up to date (Stable)" in NCC — identical firmware, config sync OK.
A third, unrelated spoke exists in the org, MAC D8:EC:E5:B6:D1:54.

Symptom

Tunnel never establishes, fails in a tight retry loop 24/7. Phase 1 (IKE_SA_INIT) always succeeds with a matching proposal (AES128-CBC / HMAC-SHA256 / DH2048). Phase 2 (IKE_AUTH) fails every time right after AUTH is received:

[SA] : No proposal chosen
IPsec SA negotiation failed
[ID] : Tunnel [SA_D8ECE5B6D154_11] Phase 1 Peer ID mismatch

Key finding

The failing tunnel object on the hub, SA_D8ECE5B6D154_11, is named after the MAC of a different spoke in our org — not the store actually connecting. Even though the correct store's WAN IP and identity (IDi) are presented, the hub validates against the other spoke's expected identity → ID mismatch → no Phase 2 policy selected → "No proposal chosen".

A second tunnel object also exists for this spoke, correctly named after its real MAC (SA_FC22F4F6C159_11), but pointed at the spoke's internal LAN address instead of its WAN IP ("Peer not reachable"). Looks like destination address and peer identity got cross-referenced between two spoke entries in the topology.

Onset

Our log pipeline (hub logs forwarded off-box) shows near-zero background occurrences before, then a clean step-change to ~1,000 occurrences/12h starting 2026-08-27 ~12:00 UTC, continuous since. No known config change on our end that day.

Already ruled out

Firmware/config mismatch between hub and spoke (identical, both synced).
Transient/cached state: disabled/re-enabled the spoke's VPN in Nebula (DNS + tunnel refresh confirmed in logs) — no change.
Cipher/PFS mismatch: Phase 1 proposal matches fine on both sides.

Question

Is this a known Nebula SD-VPN topology-generation issue on USG FLEX 200 (V5.42/ABUI.1)? How can a spoke's tunnel get validated against a different spoke's identity, and is there a way to force-rebuild a single spoke's tunnel object without touching the rest of the mesh?

Happy to enable Support Access and share config exports if useful.