Ipsec service not starting

Copy paste from CLI:
BusyBox v1.34.1 (2025-02-11 13:38:05 UTC) built-in shell (ash)

____        _    ___  ____

| _ \ _ | | / _ / |
| |
) | | | | | | | _
| _ <| |
| | |
| || |) |
|
| _\
,|_|__/|____/

 Teltonika RUTX series 2025

Device: RUTX50
Kernel: 5.10.229
Firmware: RUTX_R_00.07.12.3
Build: f600ff13a53
Build date: 2025-02-12 15:03:13

root@RUTX50:~# ipsec status
-ash: ipsec: not found
root@RUTX50:~# ipsec statusall
-ash: ipsec: not found
root@RUTX50:~#

Easy solution?

Hello,

The IPsec commands have been migrated to swanctl from firmware version 7.11. Please use the following syntax instead:

  • To check the IPsec status:
/etc/init.d/swanctl get_status
  • To restart the IPsec service:
/etc/init.d/swanctl restart

Let me know if you need further assistance or have any additional questions.

Best regards,

Seems IPSEC does not manage to establish the VPN, this only happended after latest firmware was instaled. Out of 88 devices we now have 26 that are strugeling to conect VPN.

This seems to be the problem, idk what this means. But maybe it helps someone that does understand?

strongSwan swanctl 5.9.14
plugin ‘pkcs7’: failed to load - pkcs7_plugin_create not found and no plugin file available
plugin ‘kdf’: failed to load - kdf_plugin_create not found and no plugin file available
plugin ‘curl’: failed to load - curl_plugin_create not found and no plugin file available
uptime: 16 days, since Feb 17 10:12:04 2025
worker threads: 16 total, 11 idle, working: 4/0/1/0
job queues: 0/0/0/0
jobs scheduled: 0
IKE_SAs: 0 total, 0 half-open
loaded plugins: charon des sha1 md4 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pgp pem openssl pkcs8 xcbc kernel-netlink socket-default connmark vici updown eap-identity eap-mschapv2 xauth-generic
Connection list:
plugin ‘pkcs7’: failed to load - pkcs7_plugin_create not found and no plugin file available
plugin ‘kdf’: failed to load - kdf_plugin_create not found and no plugin file available
plugin ‘curl’: failed to load - curl_plugin_create not found and no plugin file available
Azure: IKEv2, no reauthentication, rekeying every 28800s
local: %any
remote: **********************************************
local pre-shared key authentication:
id: ***************************************************
remote pre-shared key authentication:
id: ************************************************
Azure_c: TUNNEL, rekeying every 13090s
local: 10.30.49.112/28
remote: 10.20.0.0/22
Security Association list:
plugin ‘pkcs7’: failed to load - pkcs7_plugin_create not found and no plugin file available
plugin ‘kdf’: failed to load - kdf_plugin_create not found and no plugin file available
plugin ‘curl’: failed to load - curl_plugin_create not found and no plugin file available

(**************************** = our links)

Hello @Isbj0rn,

Thank you for providing the additional logs.

From the swanctl logs, it appears that no IKE security associations have been established. Could you please check if the pre-shared keys on both ends match exactly? Also, verify that both ends are using IKEv2 and that the IKE proposals/versions align correctly.

Furthermore, there are a few known issues with IPsec in correlation with Failover and cases where the client does not reconnect after the server device is rebooted. Maybe you have a similar setup or a relevant case? These issues are expected to be fixed with the upcoming 7.13.2 and 7.14 firmware releases.

I hope this will shed some light on your case, and let me know if you need any further assistance.

Best regards,

Seems to solve the issue for a while, so keys and IKVe2 seems to be working. But only for while. :frowning:

When can we expect the release of firmware that fixes this issue?

Hello,

Could you confirm if the initial issue is still present on the latest 7.13.1 RutOS firmware?

Additionally, could you provide more details on when your IPsec client disconnects and when the swanctl restart is necessary to re-establish the connection? As mentioned previously, there is a known IPsec issue where the client does not reconnect after the server is restarted. If this aligns with your case, the fix is expected to be included in the 7.14 firmware release.

Best regards,