I confirmed rolling does properly put the zabbix agent in the requested VRF
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Apr 24 2026
Apr 23 2026
@j.vela, are you sure that it is not working for 1.5?
Apr 22 2026
Apr 21 2026
We are not going to change it for Sagitta.
Changed for the current/circinus
Apr 20 2026
Apr 18 2026
Apr 17 2026
In failover mode, only one interface is active at a time.
I was going through the code in:
Apr 16 2026
Apr 15 2026
I have found validated OpenSSL FIPS https://openssl-library.org/source/
Version Certificate Security Policy FIPS Version 3.1.2 certificate security policy FIPS 140-3 3.0.9 certificate security policy FIPS 140-2 3.0.8 certificate security policy FIPS 140-2 3.0.0 certificate security policy FIPS 140-2
We are interested in 140-3
I can test in a POC
Yes, that will be enough.
Thanks, how would it link with the feature root tasks?
Apr 14 2026
We actually used Stream because we were planning to migrate to license and migrate to LTS, the GA was so close when we started our roll out we decided to go with Stream for now. Is that functionality in 1.5 GA, I can test in a POC with rolling but not I'm going to put our DC on rolling.
It is not a bug. This feature was never backported to the stream.
@dmillsq, can you re-check on the rolling to see if all works as expected before we can backport it to the stream?
The binary is compatible with Debian 13, so it also requires updating openssh-server/openssh-client/etc
https://salsa.debian.org/debian/openssl/-/blob/debian/openssl-3.5.4-1_deb13u1/debian/control?ref_type=tags#L71
Apr 13 2026
Requires an updated dpkg-dev version, so a workaround to get it
Apr 10 2026
Apr 9 2026
Apr 7 2026
Apr 6 2026
Note this issue is also in stream 2026.03
Went with the pN suffix as suggested by @c-po. Port 0 keeps the base name for backward compatibility, ports 1+ get pN appended.
Apr 5 2026
Apr 4 2026
Apr 3 2026
Submitted a PR on this.
Looking at this a bit further, this appears to be related to the VRF. Something between earlier versions of 1.5 and now have made VRF'ing for the API either unstable or unusable. I can commit any key name succesfully as long as I don't have a vrf specified, and then if I come back in after the first commit and add the vrf, VyOS accepts it - however the performance of the API then becomes extremely spotty.
Apr 2 2026
Mar 31 2026
The issue here is caused by the line set firewall zone wan from vyos firewall name 'Any-WAN-v4'
Mar 30 2026
Mar 27 2026
Mar 26 2026
@c-po fair enough. That would end up looking like this though:
usb0b1.4.1p1.0
usb0b1.4.1p1.0p1
usb0b1.4.1p1.0p2
usb0b1.4.1p1.0p3