To reproduce:

set interfaces ethernet eth2 vif 35
set interfaces pppoe pppoe0 authentication password 'MYPASSWORD'
set interfaces pppoe pppoe0 authentication user 'MYUSER'
set interfaces pppoe pppoe0 default-route 'force'
set interfaces pppoe pppoe0 mtu '1492'
set interfaces pppoe pppoe0 redirect 'ifb0'
set interfaces pppoe pppoe0 source-interface 'eth2.35'
set interfaces pppoe pppoe0 traffic-policy out 'OUT2'
set interfaces input ifb0

Commit:

vyos@r11-roll# commit
[ interfaces pppoe pppoe0 redirect ifb0 ]
Cannot find device "pppoe0"
tc qdisc ingress failed at /opt/vyatta/sbin/vyatta-qos.pl line 334.

There is a reason https://github.com/vyos/vyatta-cfg-vpn/blob/de19cb9b03b78c4e3da93e014764bb2400ffe8a6/scripts/vpn-config.pl#L34

@Viacheslav found the source of the restriction:

As both PRs have been merged now, I'm resolving this issue.

I would not call this a bug as this is produced on intention.

PR https://github.com/vyos/vyos-1x/pull/1055

The issue even with 00:00 format

The similar FRR tasks
https://github.com/FRRouting/frr/issues/9020
https://github.com/FRRouting/frr/issues/2350

Reverted back to "4.19.195"

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.

For this we create text files as the group-config includes (they contain route and other per group config directives, generally around security).

In T3896#107997, @Viacheslav wrote:

@SquirePug Can you share more details, which templates and parameters did you edit?

@SquirePug Can you share more details, which templates and parameters did you edit?

The same bug described there T2845

Acknowledged. Tested on 1.3.0-epa1

@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?

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.

@zoenan7 You can get it here https://vyos.net/get/

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 protected]

@fetzerms Can you check it in 1.4?
For example:

set policy local-route rule 10 fwmark '42'
set policy local-route rule 10 set table '100'

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,

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):

How does e.g. syslog-ng behave?

This is a typo in the documentation. In the real system, the facility is called security, but it is deprecated at least from the 2004 year.
The problem that I see in names is that it seems that different systems and software may use slightly different names for facilities. So, could be a good idea to do the two things:

• check existing and add missing facility names in CLI
• in the actual configuration transparently convert facilities to numeric representation to avoid software issues (like deprecated security facility in rsyslog).

@Viacheslav this ticket can be closed.

I closed it. Can't reproduce it.
Re-open it if necessary. Just attach your vpn configuration.