Page MenuHomeVyOS Platform

ipsec: strongswan-starter re-enabled on circinus, tunnels down on first boot
Open, HighPublicBUG

Description

vyos-build 4cd22d51 (T9283, cherry-pick of rolling 99cd4909) removed systemctl disable strongswan-starter.service from data/live-build-config/hooks/live/18-enable-disable_services.chroot. That is correct for rolling (strongSwan 6.0.7 has no starter), but circinus still ships strongSwan 5.9.11 with the starter, so the unit is now enabled.

On the first boot of a circinus image the starter's charon takes UDP 500/4500, and VyOS's charon-systemd cannot bind (unable to bind socket: Address already in use, could not create any sockets). Tunnels stay CONNECTING with no error at commit or boot, until a second reboot.

Upgrade from 1.5.1: a router with a working PSK site-to-site tunnel, add system image (default answers), reboot. On the first boot of the new image:

$ ss -ulnp | grep -E ':500|:4500'
UNCONN 0 0 0.0.0.0:4500 0.0.0.0:* users:(("charon",pid=1404,fd=17))
UNCONN 0 0 0.0.0.0:500 0.0.0.0:* users:(("charon",pid=1404,fd=16))
$ show vpn ipsec sa
Connection    State    Uptime    Bytes In/Out    Packets In/Out    Remote address    Remote ID    Proposal
------------  -------  --------  --------------  ----------------  ----------------  -----------  ----------
$ show log ipsec | tail -1
Oct 24 02:20:39 charon-systemd[2787]: no socket implementation registered, sending failed

The tunnel is down for the whole boot and comes up after a second reboot.

Fresh install: the starter is active before any configuration. A minimal IKEv2 PSK site-to-site peer commits fine, but after 60 s show vpn ipsec sa is empty with the same bind errors. 1.5.1 and rolling establish the tunnel right away.

Why only the first boot: the image ships the package's /etc/ipsec.conf, and the starter starts before VyOS applies its configuration. vyos-router then deletes the file in security_reset, so later boots of the same image are clean.

Proposed fix, tested: restore the line in the circinus hook while circinus ships strongSwan 5.9.

 systemctl disable strongswan.service
+systemctl disable strongswan-starter.service

With it the starter is inactive on first boot. The upgrade keeps the tunnel up and a fresh install establishes it.

Details

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