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

It is a bug that it’s on by default, see other task. Will be fixed after new firewall refactor is merged.

From the VyOS documentation and https://community.openvpn.net/openvpn/wiki/DataChannelOffload

Then how come conntrack modules are loaded (and there is content in the ruleset "sudo nft -s list ruleset") when I have no firewall rules configured?

CLI adjusted to:

Conntrack should be disabled by default https://vyos.dev/T5080

It is not a bug.
It is the implementation of TACACS authentication https://github.com/vyos/vyos-1x/pull/2038
https://github.com/vyos/vyos-1x/blob/fa07179ae7f1dc07e6ccc1b20d2b81384b6efe07/debian/vyos-1x.postinst#L47-L52

Tested and verified as described in the pull request:

Thanks for testing and submitting PR

Pull request created: https://github.com/vyos/vyos-1x/pull/2112

There is this line in the code https://github.com/vyos/vyos-1x/blob/688755a988e233e221bf920e391e35d5ddc9cb56/src/op_mode/show_ntp.sh#L21

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

@c-po just added the sudo on a live box to test the changes and I can confirm that fixes it. No auth prompt when doing a load config.
Now I did notice that every time I do a load config it runs that migration script which stops/starts the container which is not ideal.

I can confirm that altering line 21 as suggested fixes this issue.

We probably wan't to load/unload the Kernel Module given what the user want's to do

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

Out of the blue it seems like "network namespaces" would solve alot of current VRF compatability issues within VyOS:

Workaround until "system name-server" becomes vrf aware seems to be to change context into vrf INTERNET and then do a ping with VRF syntax like so:

I would vote for:

PR: https://github.com/vyos/vyos-1x/pull/2108
PR: https://github.com/vyos/vyos-build/pull/372

Can you check changing

@jvoss Add the PR, please
Thanks.

Spot on Viacheslav! That absolutely resolved the issue, thanks! I was initially thinking it might have been the key_mangling option. Glad to see there is another option here.

Try to add no_tag_node_value_mangle there https://github.com/vyos/vyos-1x/blob/20b7155f4140f54cf7669256160b6fedd8c1ab7a/src/conf_mode/protocols_static.py#L50

Doing some more digging it turned out that VyOS doesnt support nested routing so the gateway must be reachable (at least IP-address wise) through a physical interface - I have updated the script in the original post to adjust for that (added variable GATEWAY).

@dongjunbo It requires more tests and reviews

Fix for 1.4: https://github.com/vyos/vyos-1x/pull/2109

Would you please backport this feature to VyOS 1.3.x?

I would find something like this very easy to use:

Re opening this task. Migration script needs to be added.

Do you have any idea for the CLI?

But they shouldnt take several minutes and this alone can be a reason for why not putting VyOS into production.

Long commit time does not depend on the number of static routes, but on a size of the configuration or number of lines in the configuration. If a router has a large configuration (not necessarily static routes), committing any changes takes several minutes.

PR:
https://github.com/vyos/vyos1x-config/pull/19

PR:
https://github.com/vyos/vyos1x-config/pull/19

Am I supposed to create data/template/dhcp-client/dhcp6c_daemon-options.j2 by hand? I tried to run make to try and create the template, then go from there & fill out the template like in daemon-options.j2. But my dev env is borked, and I'm starting to think that inside a VyOS instance is also where I'm supposed to do this.