| Age | Commit message (Collapse) | Author |
|---|
|
http-api: T3955: add commit-confirm to endpoints /configure /config-file
|
|
openconnect: T7511: bugfix invalid variable name
|
|
op-mode: T7459: eliminate direct use of sudo in op mode commands
|
|
|
|
|
|
|
|
|
|
|
|
T6013: Add support for AuthorizedPrincipalsFile to trusted_user_ca_key
|
|
* zebra: T7349: Added importing routes from non to the kernel routing table
Added importing routes from non to the kernel routing table.
---------
Co-authored-by: Christian Breunig <christian@breunig.cc>
|
|
http-api: T7498: allow passing config string in body of 'load' or 'merge' request
|
|
The current implementation for SSH CA based authentication uses "set service
ssh trusted-user-ca-key ca-certificate <foo>" to define an X.509 certificate
from "set pki ca <foo> ..." - fun fact, native OpenSSH does not support X.509
certificates and only runs with OpenSSH ssh-keygen generated RSA or EC keys.
This commit changes the bahavior to support antive certificates generated using
ssh-keygen and loaded to our PKI tree. As the previous implementation
did not work at all, no migrations cript is used.
|
|
We need to establish proper dependencies on "system login" and "pki ca" for
the SSH subsystem. If the CA is updated or user principal names are modified,
we must also ensure that the SSH daemon is restarted accordingly.
|
|
We already support using per-user SSH public keys for system authentication.
Instead of introducing a new CLI path to configure per-user principal names,
we should continue using the existing CLI location and store the principal
names alongside the corresponding SSH public keys.
set system login user <name> principal <principal>
The certificate used for SSH authentication contains an embedded principal
name, which is defined under this CLI node. Only users with matching principal
names are permitted to log in.
|
|
Thisc omplements commit e7cab89f9f81 ("T6013: Add support for configuring
TrustedUserCAKeys in SSH service with local and remote CA keys"). It introduces
a new CLI node per user to support defining the authorized principals used by
any given PKI certificate. It is now possible to associate SSH login users with
their respective principals.
Authored-by: Takeru Hayasaka <hayatake396@gmail.com>
|
|
|
|
|
|
|
|
|
|
Added another possible condition to the flow through the config apply function
so that interfaces will reconnect as expected, even when there has been no
significant change to the contig tags.
|
|
flowtable: T7350: Prevent interface deletion if referenced on flowtable
|
|
QoS: T7415: Fix tcp flags matching
|
|
Bridge: T7430: Add BPDU Guard and Root Guard support
|
|
|
|
|
|
|
|
|
|
Empty leaf nodes are cleaned, causing the tcp
ack and syn flags to not match. These values are exempted from being cleaned.
|
|
|
|
|
|
T1771: automatic reboot of system into previous image
|
|
pppoe: T7463: Added restart if CoA is changed
|
|
Added a restart if CoA is changed
Added a restart if the authentication mode is changed
|
|
prometheus: T7435: Ensure only configured exporters are started
|
|
opennhrp: T7462: Removed unused opennhrp files and configurations
|
|
wireguard: T7387: Optimise wireguard peer handling
|
|
policy: T5069: large-community-list regex validator disallows whitespace
|
|
openconnect: T7287: VPN Openconnect does not check dictionary key se…
|
|
Removed unused opennhrp files and configurations
|
|
with authentication mode RADIUS
|
|
If any part of the system boot fails, we set overall_status=1 in the vyos-router
startup script. When an error during the image upgrade is detected, the system
will automatically revert the default boot image to the previously used version,
if the CLI option "system option reboot-on-upgrade-failure" is set.
The user is informed via console messages:
Booting failed, reverting to previous image
Automatic reboot in 5 minutes
Use "reboot cancel" to cancel
The user has time to log in and run reboot cancel to remain in the faulty image
for troubleshooting. Reboot timeout is defined by CLI: "system option
reboot-on-upgrade-failure"
Once the system boots into the previous image, the MOTD will display a
persistent warning message - cleared during next reboot.
WARNING: Image update to "VyOS 1.5.xxxx" failed
Please check the logs:
/usr/lib/live/mount/persistence/boot/NAME/rw/var/log
Message is cleared on next reboot!
Upgrade failure can be synthetically injected by booting with Kernel command
line option: vyos-fail-migration
|
|
When performing an image upgrade we will create a file named /config/first_boot
with JSON data inside the new images persistent storage. The content of the file
will look like: {"previous_image": "1.5-stream-2025-Q3"}
The previous image name can be easily queried using "jq -r '.previous_image'".
This is the base work required for an adjusted version of the vyos-router init
script to support an automatic rollback to a previous image if things go
sideways.
|
|
|
|
VPN IPsec unexpected passthrough logic bug was introduced in this
commit https://github.com/vyos/vyos-1x/commit/f480346bb8e934b1ce2e0fc3be23f7168273bba1
The correct behaviour of the `cidr_fit` was replaced with the
incorrect `overlap`
This way, the passthrough option is used every time when networks overlap.
```
>>> from ipaddress import ip_network
>>>
>>> a = ip_network('192.0.2.0/24')
>>> b = ip_network('192.0.2.100/30')
>>>
>>> a.overlaps(b)
True
>>>
>>> b.overlaps(a)
True
>>>
```
But there should be `subnet_of`:
```
>>> a.subnet_of(b)
False
>>>
>>> b.subnet_of(a)
True
>>>
```
In configuration it looks like
```
set vpn ipsec site-to-site peer RIGHT tunnel 0 local prefix '192.0.2.0/24'
set vpn ipsec site-to-site peer RIGHT tunnel 0 remote prefix '192.0.2.100/30'
```
The StrongSwan unexpected configuration:
```
RIGHT-tunnel-0-passthrough {
local_ts = 192.0.2.0/24
remote_ts = 192.0.2.0/24
start_action = trap
mode = pass
}
```
So all outcoming traffic to the 192.0.2.0/24 pass through the main routing
table instead of out SA
Use `subnet_of` to fix this
|
|
T7157: bgp: Added verification of the route-map existence in vrf import
|
|
T7386: firewall: Allow IPv6 member in firewall remote-groups
|
|
Added verification of the route-map existence in the vrf
route-leaking.
|
|
frr: T7411: preserve FRR config on service restart if it exists
|
|
haproxy: T7429: remove unsupported logging facility and log level
|
|
T7423: Add kernel boot options isolcpus, hugepages, numa_balancing
|
