VyOS command definitions, scripts, and utilities (mirror of https://github.com/vyos/vyos-1x.git) https://git.amelek.net/vyos/vyos-1x.git/atom?h=rolling 2026-06-25T14:36:22+00:00 2026-06-25T14:36:22+00:00 Christian Breunig christian@breunig.cc 2026-06-25T14:36:22+00:00 urn:sha1:fe78ab4165456fd1d7bcd2ec99d7601dc2e71d2c T8097: strongswan: add CLI for ESN 2026-06-22T18:24:49+00:00 Kyrylo Yatsenko hedrok@gmail.com 2026-06-19T16:14:46+00:00 urn:sha1:7693c06dc1c5fecb71bf2d21c140ac1bbd5a1088 Add options for mlkem* 2026-06-20T06:59:00+00:00 Kyrylo Yatsenko hedrok@gmail.com 2026-06-20T06:37:42+00:00 urn:sha1:e8611801c7f36d7942ed367c5cf0b0dfd08083d2 Add CLI commands: set vpn ipsec ike-group MyIKEGroup proposal 1 esn ESN-VALUE set vpn ipsec esp-group MyESPGroup proposal 1 esn ESN-VALUE Where ESN-VALUE can be one of: * required: only establish connection using ESN * optional: try using ESN, but if not available, accept non-ESN * disabled (default): don't use ESN StrongSwan 6.0.6 doesn't allow connections between proposal with '-noesn' and without '-esn'/'-noesn'. To make it work as expected, use two proposals for 'optional' and 'disabled': * required: PROPOSAL-esn * optional: PROPOSAL-esn-noesn,PROPOSAL * disabled: PROPOSAL-noesn,PROPOSAL 2026-05-27T14:04:17+00:00 Oleksandr Kuchmystyi o.kuchmystyi@vyos.io 2026-05-27T13:31:15+00:00 urn:sha1:3b22850f4fe4163fea73f907ba8fe72777ba8d80 When setting 'vpn ipsec logging log-level 0', DPD informational messages (log level 1) were still appearing in the system journal. The root cause is that charon-systemd reads both `charon-systemd.conf` and `charon-logging.conf` and applies the higher of the two log levels to the journal. The VyOS only managed `charon-systemd.conf`, leaving `charon-logging.conf` at its default level of 1, which silently overrode the user-configured level. Fix this by rendering `charon-logging.conf` on every commit with syslog backend set to -1 (silent), making `charon-systemd.conf` the sole authoritative source for journal log verbosity. This also eliminates duplicate log entries in the journal that occurred when both backends were active and writing to the same destination. 2026-05-20T09:22:21+00:00 Oleksandr Kuchmystyi o.kuchmystyi@vyos.io 2026-05-14T09:42:44+00:00 urn:sha1:b6d24956bd4c7a5e4cb89c0b4331264a96667184 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). 2026-04-27T08:39:46+00:00 Yahya Civelek yahyacivelek@ulakhaberlesme.com.tr 2026-04-27T08:39:46+00:00 urn:sha1:d58ca8f6d837d7f832e51abcc29440de0f653bde The following nodes specified u32 but their range values exceed the uint32 maximum (4,294,967,295): - service lldp interface location coordinate-based elin: u32:0-9999999999 -> u64:0-9999999999 - vpn ipsec esp-group life-bytes: u32:1024-26843545600000 -> u64:1024-26843545600000 - vpn ipsec esp-group life-packets: u32:1000-26843545600000 -> u64:1000-26843545600000 2026-03-24T17:02:56+00:00 Viacheslav Hletenko v.gletenko@vyos.io 2026-03-20T16:41:24+00:00 urn:sha1:bb2aee1e58c1cd30087b935798060e6bf3c698c8 Fix typos and mistakes in the commands and comments No functional changes 2026-03-04T04:48:18+00:00 Giga Murphy giga1699@gmail.com 2026-01-02T01:04:38+00:00 urn:sha1:673ec335b885ae1de8391dd8c48a5fe16b282db5 2025-12-04T15:03:54+00:00 Oleksandr Kuchmystyi o.kuchmystyi@vyos.io 2025-11-28T14:52:59+00:00 urn:sha1:2dc91c0a96c3d3212387be02b80c58fce7c68bd8 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. 2025-11-22T02:22:43+00:00 Chris Cowart ccowart@timesinks.net 2025-11-16T06:39:53+00:00 urn:sha1:090c4afe8dce25f772c24fc9bb6e3b96d23fcc2b This setting seems to be required for various Apple clients to connect to the IKEv2 IPSec VPN.