When a peer rejects IKE_SA_INIT with NO_PROPOSAL_CHOSEN, a VyOS connection-type initiate peer never retries on its own. This happens for example during a coordinated change of IKE/ESP proposals, when the remote side commits a few seconds later. The tunnel stays down even after the remote side has the matching proposals, until someone runs reset vpn ipsec ... / swanctl --initiate or the config is committed again. This happens although the generated swanctl config sets keyingtries = 0 (retry forever) and start_action = start.

Steps to reproduce

Three VyOS routers in a full mesh (SITE-A initiates to SITE-B and SITE-C; SITE-B initiates to SITE-C; the others use connection-type none), all tunnels up.

1. On all routers, prepare a change of the ike-group/esp-group proposals (in our case dh-group 14 → 31 together with a policy-based → VTI migration of the same peers).
2. Commit on SITE-A first; commit on SITE-B and SITE-C about 10–15 s later.

Observed

SITE-A initiates immediately with the new proposals and gets NO_PROPOSAL_CHOSEN, because SITE-B/C still have the old config:

02:31:18 charon: 08[CFG] initiating 'SITE-C-vti'
02:31:18 charon: 16[ENC] <SITE-C|6> parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
02:31:18 charon: 16[IKE] <SITE-C|6> received NO_PROPOSAL_CHOSEN notify error
02:31:18 charon: 11[CFG] initiating 'SITE-B-vti'
02:31:18 charon: 09[ENC] <SITE-B|7> parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
02:31:18 charon: 09[IKE] <SITE-B|7> received NO_PROPOSAL_CHOSEN notify error
02:31:29 (SITE-B commits the matching config)
02:31:34 (SITE-C commits the matching config)

After that, no new IKE_SA_INIT is sent to SITE-B or SITE-C. The tunnels stayed down for 5 minutes, until our commit-confirm timer reverted the configuration. The same happened on SITE-B toward SITE-C (initiated at 02:31:25, SITE-C committed at 02:31:34).

Generated swanctl settings for these peers:

keyingtries = 0
start_action = start
dpd_action = restart

dpd_action/close_action do not help here, because no IKE_SA was ever established.

Workaround

• Commit the responders first and the initiators last, and/or
• after the change, on each initiator: sudo swanctl --initiate --child <peer>-vti (or reset vpn ipsec site-to-site peer <peer>).

With that order the same change succeeded on the second attempt (all tunnels up within seconds).

Expected / suggestions

• For connection-type initiate, VyOS could re-initiate periodically (with backoff) while the connection is not established. It could also treat NO_PROPOSAL_CHOSEN / AUTH_FAILED as retryable, since keyingtries = 0 suggests "retry forever".
• At least, the docs for connection-type initiate and for changing proposals should say that a rejected negotiation is not retried, and recommend the commit order or a reset vpn ipsec afterwards.