Jessie based VyOS - Crux
Sat, Oct 23
Reverted back to "4.19.195"
Fri, Oct 22
https://github.com/vyos/vyos-build/commit/402d80498683f298be1dd3581cb0143362ceb561 - developers are reverting to kernel 4.19.207. But this is the kernel that started the problem.
Sun, Oct 17
Thu, Oct 14
For this we create text files as the group-config includes (they contain route and other per group config directives, generally around security).
Tue, Oct 12
Mon, Oct 11
@SquirePug Can you share more details, which templates and parameters did you edit?
Fri, Oct 8
Mon, Oct 4
The same bug described there T2845
Acknowledged. Tested on 1.3.0-epa1
Tue, Sep 28
Sep 26 2021
Sep 13 2021
Sep 12 2021
Sep 7 2021
@absolutesantaja this is definately a bug in the 1.2.9 op-mode commands
Are you saying "show interfaces wireguard" is being back-ported to crux 1.2.9 or something? If not then the crux documentation is still wrong.
The operational command "show interfaces <interface-type> " has been fixed in the latest rolling and equuleus release.
May I ask whether the vulnerability report should be made public here or submitted to which mailbox? Will a PGP public key be provided to encrypt sensitive information?
Sep 6 2021
Sep 5 2021
Here is the screenshot of vulnerability reproduction.
I tried to reproduce the vulnerability we found on v1.2.7 version of VyOS and debug the vulnerability, hoping to provide you with a detailed vulnerability report.
Sep 4 2021
Hello, I can't find the latest version of VyOS on the Internet. Could you please provide a mirror image to my mailbox? I'll validate any bugs I find. My email address is email@example.com
Sep 3 2021
@fetzerms Can you check it in 1.4?
set policy local-route rule 10 fwmark '42' set policy local-route rule 10 set table '100'
Sep 2 2021
VyOS 1.1.7 is EOL and won't receive any updates. Please upgrade to 1.2 or higher
These vulnerabilities can cause the EFFECT of SNMP service Dos,
Aug 31 2021
Aug 30 2021
Aug 29 2021
VyOS 1.4 uses persistent OpenVPN interfaces.
The issue may be with OpenVPN/dynamic interfaces only, without the option "persist".
In that case, if no connectivity between interfaces it tried to re-add the interface "down/up" vtunX with a new SNMP index. And it will be in the loop until connectivity will be restored with the remote site.
Not seeing this issue when setting "description" field - we've run it in production for years bridging our OpenStack and datacenter environments, and the names show up correctly (blanked sensitive details):