NFT rate-limiting is effectively a policer instead of a shaper, so I don't think it'd be a good way to accomplish this. All drops would be aggressive and not tail-drops.

Also the config section could perhaps be name "custom" (with subsections) so that section will survive an upgrade aswell - otherwise config lines will vanish during boot/commit.

Duplicate

On testing, it looks like vyos.utils.network.get_vxlan_vni_filter() doesn't know how to handle when there are no vni filters installed.

I've created a quick PR to give sane feedback from the validator: https://github.com/vyos/vyos-1x/pull/3572

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

Tested as working in: VyOS 1.5-rolling-202405310019

I've created a PR for this that fixed a mistake with my original patch: https://github.com/vyos/vyos-1x/pull/3570

In https://github.com/vyos/vyos-rolling-nightly-builds/releases/tag/1.5-rolling-202405301617 wrote

set resource-group username-group <my-users> username user01 password '09078081'
set resource-group username-group <my-users> username user02 password 'fmndskl82'

set service pppoe-server authentication local-users username-group 'my-users'
set vpn l2tp remote-access authentication local-users username-group 'my-users'
set vpn sstp authentication local-users username-group 'my-users'
set vpn openconnect authentication local-users username-group 'my-users'

Looks like what I was talking about

Need a general place to store accounts for VPN; whether it is a local radius server or chap-secrets file(this option seems simpler and more correct) is not so important.
A separate radius server is another point of failure and a separate infrastructure object. Wants to have a boxed solution where everything is available at once

https://github.com/vyos/vyos-1x/pull/3552

Apple IOS now recognizes multiple CAs inside the profile

With this change all CAs in the list are rendered into the template.

In T6417#190336, @Viacheslav wrote:

It is not clear why it should be ignored? If they should be ignored they must not be in the CLI at all.
Why not use RADIUS authentication for it?

Do I get it wrong? Local RADIUS server seems like overhead here. Are we talking about the local “chap-secrets” file that can be reused by other daemons or RADIUS?
Clarify please the feature request.

Need a general place to store accounts for VPN; whether it is a local radius server or chap-secrets file(this option seems simpler and more correct) is not so important.
A separate radius server is another point of failure and a separate infrastructure object. Wants to have a boxed solution where everything is available at once

The similar task T6409

It is not clear why it should be ignored? If they should be ignored they must not be in the CLI at all.
Why not use RADIUS authentication for it?

https://github.com/vyos/vyos-1x/pull/3546

Tested as working in: VyOS 1.5-rolling-202405280020

@mersl thanks for confirm.

In T6417#190277, @Viacheslav wrote:

It probably cannot be a universal solution due to specific per-user options.
For example, for opencoonect, you can add otp if you want on a per-user basis and not do it for other users.

vyos@r4# set vpn openconnect authentication local-users username foo 
Possible completions:
   disable              Disable instance
 > otp                  2FA OTP authentication parameters
   password             Password used for authentication

Another case specific client IP address or rate limit

vyos@r4# set vpn sstp authentication local-users username foo 
Possible completions:
   disable              Disable instance
   password             Password for authentication
 > rate-limit           Upload/Download speed limits
   static-ip            Static client IP address (default: *)

Though it could be only for accel-ppp based configuration sstp/l2tp/pptp

specific per-user options can ignored if the protocol does not support them

just some show commands with test results on my lab

very cool! I just rebuild a 1.5-rolling and upgraded my lab router and voila - works as expected ;-)

It probably cannot be a universal solution due to specific per-user options.
For example, for opencoonect, you can add otp if you want on a per-user basis and not do it for other users.

vyos@r4# set vpn openconnect authentication local-users username foo 
Possible completions:
   disable              Disable instance
 > otp                  2FA OTP authentication parameters
   password             Password used for authentication