Hope we need to run this for smoke test
https://github.com/vyos/vyos-1x?tab=readme-ov-file#tests

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

For this, need to get details on our existing smoke tests.

@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

we've added this ability to configure the topology on isis :

agree ,it's more a feature than a bug : PR https://github.com/vyos/vyos-1x/pull/3537

Are you sure your DHCP server honors the no-default-route option?
I may be wrong, but I think the no-default-route just sets an option in the DHCP request, asking the DHCP server to not send back the default route.
I have the same issue with my ISP, and they told me they will always send a default route via DHCP.
I have solved the issue using DHCP hooks.

More a feature request than a bug

We will bind the code to a new command in operating mode (for example show ports). This will allow you to use the nmap command from operating mode. Just a convenient feature.

the problem here is that MT options is enable by default when the RIB has ipv4, if not not-MT is enable by default on IPv4 .So, you need to add additional topologies (ipv6-unicast , ipv6-multicast,etc)

Fix link:
https://github.com/vyos/vyos-1x/pull/3529

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

@Viacheslav here you go:

Can you provide set of commands instead? Bug-report-guidelines

@ssasso - thanks for this good catch! Coming from a Junos world, I was a bit surprised at the first place when I enabled ISIS and found no ipv6 isis routes and no multi-topology config option (and yes - we have multi-topology in place)

The charon identifier also shows IKE name of the SA; this way, we can identify peers in the logs https://github.com/vyos/vyos-build/blob/b809886538eaad66b8756be8f5e758584f88e6a6/data/live-build-config/hooks/live/30-strongswan-configs.chroot#L41-L54
The current show log vpn does https://github.com/vyos/vyos-1x/blob/48e5266e2bca8d1d7a2ee4bacbe0e6628de3fa66/op-mode-definitions/show-log.xml.in#L710

@rob Thanks for the confirmation.
I will keep submodules.yml , update-translations.yml as is in vyos-documentation

Raised PR for first 3 workflows
https://github.com/vyos/vyos-documentation/pull/1464

submodules.yml ===> do we need to move?
update-translations.yml ==> as you said, we dont need to move

@syncer pl let me know in this,
update-translations.yml - will keep it local to repo.
And other workflows, can I move to global?
https://github.com/vyos/vyos-documentation/tree/current/.github/workflows

Ok, Thanks @syncer and @rob.

In T6410#190062, @Vijayakumar wrote:

Thanks.

And i am moving this workflow "update-translations.yml" to global ,github
But couldn't find below make target code.
https://github.com/vyos/vyos-documentation/blob/current/.github/workflows/update-translations.yml#L33
Could you pls guide me?

Just dont, please see my comment fro april 2024.

In T6410#190062, @Vijayakumar wrote:

Thanks.

And i am moving this workflow "update-translations.yml" to global ,github
But couldn't find below make target code.
https://github.com/vyos/vyos-documentation/blob/current/.github/workflows/update-translations.yml#L33
Could you pls guide me?

And i am moving this workflow "update-translations.yml" to global ,github
But couldn't find below make target code.
https://github.com/vyos/vyos-documentation/blob/current/.github/workflows/update-translations.yml#L33
Could you pls guide me?

@sever what about it?

this repo will have own codeowners file, reviewers team is only for code repos

@Vijayakumar added

Please provide me write access to https://github.com/vyos/vyos-documentation.
Also please provide vyos/reviewers team write access for this repo (required as codeowners)

tested new cli structure, it combine the new mach-group and old syntax :

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

The dependency allowed for 386/amd64 only https://github.com/vyos/vyos-build/blob/b809886538eaad66b8756be8f5e758584f88e6a6/docker/Dockerfile#L281
Though the package is available for ARM

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

As several CA were allowed some time ago it is a bug with op-mode generator.
There is a list of CA's https://github.com/vyos/vyos-1x/blob/48e5266e2bca8d1d7a2ee4bacbe0e6628de3fa66/src/op_mode/ikev2_profile_generator.py#L147
The template https://github.com/vyos/vyos-1x/blob/current/data/templates/ipsec/windows_profile.j2

I made a PR that uses an implementation with a separate function: https://github.com/vyos/vyatta-cfg/pull/79