Hi friends, I'm experiencing what appears to be the same bug. In my case, it's on a redirect on a vif subinterface on a bonding interface. So perhaps bug is not so much about PPPoE interfaces, so much as any interfaces that don't exist before the commit is done.

Trying to configure a wireguard peer with a dns name as remote endpoint. I understand this is not supported, but I see many references to creating a post-boot script to do this. Any working examples? Thank you

I think all Chaos stater after this message:

More detail :

I happened today in 17 vyos clusters after a switch failure. Same logs and no bgp process running:

The below is also not possible on route maps

Resolved in https://phabricator.vyos.net/T3774, but it will not be backported to 1.2.

@kirvio Could you check it on 1.3/1.4?

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