Page MenuHomeVyOS Platform
Create Task
Maniphest T9543

'reset vpn ipsec site-to-site peer' does not bring the tunnel back when connection-type is unset
Closed, ResolvedPublicBUG
Actions

Description

On a peer with no connection-type set, the router starts the tunnel at commit. After reset vpn ipsec site-to-site peer <name> vti it only terminates it:

vyos@prv5565-ref:~$ show configuration commands | grep -c 'PRV5565-B connection-type'
0
vyos@prv5565-ref:~$ reset vpn ipsec site-to-site peer PRV5565-B vti
Peer PRV5565-B tunnel vti terminate result: success
vyos@prv5565-ref:~$ sudo swanctl --list-sas | grep -cE 'ESTABLISHED|INSTALLED'
1
vyos@prv5565-ref:~$ ip -o link show vti10 | cut -c1-80
29: vti10@NONE: <NOARP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group def

The IKE SA stays, no child SA comes back (checked 30 s later), and vti10 is down. The other end was set to respond only. With connection-type initiate set explicitly, the same reset brings the tunnel back.

Cause: data/templates/ipsec/swanctl/peer.j2 treats an unset connection-type as initiate (start_action = start). reset_peer() in src/op_mode/ipsec.py re-initiates only when connection_type == 'initiate' is present in the config. That check came with T6148 (2024-07-28).

Possible fix (untested): in reset_peer(), also re-initiate when connection_type is absent.

Details

Version
1.5.1, 1.5-rolling-20261028
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Related Objects

Event Timeline

a.kudientsov created this task.Fri, Oct 30, 12:08 PM
pasik subscribed.Fri, Oct 30, 12:20 PM
rherold subscribed.Sat, Oct 31, 7:14 AM

I reproduced this on 2026.10.16-0024-rolling with two VMs (peer A without connection-type, peer B with connection-type none, VTI):

$ reset vpn ipsec site-to-site peer PRVB vti
Peer PRVB tunnel vti terminate result: success
(30 s later) IKE SA: 1, child SAs: 0, vti1: DOWN

With connection-type initiate set explicitly on peer A, the same reset prints terminate result: success and initiate result: success, and the child SA is back after a few seconds.

The cause is as described: the template treats an unset value as initiate, reset_peer() only looks at the configured value.

I prepared a fix instead of the proposed reset_peer() fallback, so the default exists in one place only: <defaultValue>initiate</defaultValue> in the CLI definition, and the reset command reads the peer config with defaults.

One more case came up in the lab. A peer without connection-type whose remote address is any (or whose name starts with @) is not started at commit, because there is nothing to connect to. With the new default, reset on such a peer would have printed "Failed to initiate SA for IKE <peer>" (and "Initiation was failed" for @ peers). Reset now skips these peers, as before.

Tests on the VM:

  • Smoketest with a peer to an unreachable address: after reset a new IKE SA appears. Fails with the unchanged reset command, passes with the fix.
  • Smoketest for a @ peer and a remote-address any peer: fails without the skip, passes with it.
  • The two-VM scenario above passes (child SA back after reset).
  • test_vpn_ipsec.py as a whole: 24 tests OK.

The change is ready locally as a single commit (XML default, 8 lines in src/op_mode/ipsec.py, smoketest). I can open a draft PR if that is fine.

rherold added a comment.Sat, Oct 31, 7:54 AM

PR: https://github.com/vyos/vyos-1x/pull/5615

c-po closed this task as Resolved.Sat, Oct 31, 11:05 AM
c-po assigned this task to rherold.
c-po triaged this task as Normal priority.