vyos-1x.git/data/templates/ipsec/swanctl, branch rolling

ipsec: T8952: Allow per-peer strongSwan `unique` override for site-to-site peers

2026-09-16T08:22:40+00:00

VyOS does not expose the strongSwan `connections..unique` parameter for site-to-site peers. The swanctl default is `unique = no`, which only replaces existing SAs if the new one carries `INITIAL_CONTACT`. With `dpd_action = restart`, charon initiates new IKE_SAs without `INITIAL_CONTACT`, so duplicates accumulate on every DPD timeout. Previously the strongSwan `unique` connection policy could only be driven by the global "disable-uniqreqids" option, which set it to "never" for every connection. Site-to-site peers had no way to opt into stricter enforcement on their own.

ipsec: T9254: split get_esp_ike_cipher() into get_esp_cipher() / get_ike_cipher()

2026-09-14T08:19:12+00:00

get_esp_ike_cipher() took an esn flag defaulting to True (ESP/CHILD_SA semantics), and every IKE_SA call site had to remember to pass esn=False. Nothing enforced that, so a future call site could reintroduce the ESN-in-IKE bug this task fixed. Following review feedback from hedrok, split it into two public filters: get_esp_cipher(group_config, ike_group=None) ESP/CHILD_SA, esn=True get_ike_cipher(group_config) IKE_SA, esn=False always The shared implementation moves to _get_esp_ike_cipher() (no register_filter), so a template can no longer call it directly and skip picking one of the two entry points. Updated call sites: peer.j2, profile.j2, remote_access.j2, l2tp.j2 (proposals -> get_ike_cipher, esp_proposals -> get_esp_cipher), and test_template.py.

ipsec: T9254: do not emit ESN transforms in IKE proposals

2026-08-31T17:57:40+00:00

get_esp_ike_cipher() renders both IKE_SA proposals and CHILD_SA proposals. It unconditionally appended the -esn / -noesn variants, which are only meaningful for ESP: ESN is Transform Type 5 per RFC 7296 section 3.3.2 and is defined for CHILD_SAs only. Emitting ESN in an IKE_SA proposal breaks interoperability with implementations that reject the malformed payload without replying at all. Observed against a Cisco FTD: the IKE_SA_INIT is silently discarded, no NO_PROPOSAL_CHOSEN and no INVALID_KE_PAYLOAD, so the tunnel never comes up and nothing on the initiator side explains it. Add an explicit esn parameter defaulting to True so ESP behaviour is unchanged, and pass esn=False at the four IKE call sites: peer.j2, profile.j2, remote_access.j2 and l2tp.j2. The five esp_proposals call sites keep ESN. ike_group could have served as the discriminator, since IKE call sites do not pass it, but that coupling is incidental: the argument only exists to resolve PFS. Smoke test assertions on the proposals lines are updated accordingly; the esp_proposals assertions are left untouched.

ipsec: T7555: Implement `ikev2-reauth` for site-to-site peers

2026-05-20T09:22:21+00:00

IKEv2 reauthentication was configurable via CLI but never translated into `swanctl.conf`. Add `reauth_time` to the peer connection template, driven by the `ikev2-reauth` flag on the ike-group and the per-peer override (yes/no/inherit).

T8386: fix locat_ts rendering in remote_access.j2

2026-03-17T07:02:03+00:00

T8136: IPSEC PPK Support

2026-03-04T04:48:18+00:00

ipsec: T7594: Rename `respond` connection-type in IPSec peer settings to `trap`

2025-12-04T15:03:54+00:00

The previous 'connection-type respond' option in IPsec site-to-site peers was misleading - instead of passively waiting for peer initiation, it would initiate negotiation when matching traffic appeared, potentially causing SA duplication and renegotiation loops.

T8027: vpn: adding config for swanctl "send-cert always"

2025-11-22T02:22:43+00:00

This setting seems to be required for various Apple clients to connect to the IKEv2 IPSec VPN.

ipsec: T7562: Add support for `disable-uniqreqids` option in IPsec configs

2025-08-12T09:11:05+00:00

This commit makes `set vpn ipsec disable-uniqreqids` work with the modern StrongSwan backend by setting `unique=never` in swanctl.conf for connections. This restores legacy behavior about multiple connections with the same identity.

ipsec: T7581: Fix unsupported 'all' protocol in site-to-site tunnels after upgrade to 1.4.x

2025-07-28T08:43:42+00:00

Upgrading from VyOS 1.3.8 (strongSwan 5.7.2) to 1.4.x (strongSwan 5.9.11) caused the IPsec service to fail if the configuration contained: ``` set vpn ipsec site-to-site peer tunnel protocol 'all' ``` In 1.3.8, 'all' was supported in the CLI for protocol and converted internally to '%any' in ipsec.conf traffic selectors, allowing the tunnel to match all protocols. However, in 1.4.x and strongSwan 5.9.11+, the '[all/]' syntax is no longer supported, and use of 'protocol all' produces an invalid traffic selector (e.g., 'x.x.x.0/24[all/]'), causing the strongSwan service to fail on reload. This fix ensures that 'protocol all' is converted to just the subnet notation (e.g., 'x.x.x.0/24') in the generated traffic selector, restoring previous behavior and allowing seamless service startup after upgrade.