This error not only occurs for new settings in global-options but also for older:

If there would never be such then "INVALID" wouldnt exist as an option.

2.2: Invalid shall ALWAYS be processed BEFORE established/related/other rules otherwise it will not serve it purpose.

Still works in VyOS 1.4-rolling-202308140557:

Verified in VyOS 1.4-rolling-202308140557:

Seems to still be happy in VyOS 1.4-rolling-202308140557:

Verified in VyOS 1.4-rolling-202308140557:

1:
Shouldnt set firewall global-options resolver-cache have "enable" and "disable" as options?

Looks like its working as expected in VyOS 1.4-rolling-202308140557:

What is the purpose of:

How is your IPv6 config from the VyOS config?

A workaround in the meantime:

And in that case the attacker would just replace your router with their own since they already got physical access to the box.

The problem is how to make sure that the router can boot and reboot (for example "set system option reboot-on-panic" is handy) on itself without somebody having to connect to its console before it starts to function again. Really shitty situation for a remote site because then somebody needs to visit it aswell.

1. How is the physical topology (can you provide a drawing)?

Its not possible to "symlink" it?

But at the same time it would help others who migrate to VyOS from Cisco, Arista etc.

PR created: https://github.com/vyos/vyatta-op/pull/66

Its good for traceability to get a snmp trap sent when the firewall config has been altered/changed/(re-)applied.

Yeah, no worries.

Im biased but here are my testresults using modified VyOS 1.4-rolling-202308060317:

According to https://www.kernel.org/doc/html/v6.1/admin-guide/serial-console.html

There were no screenshots included with this task?

PR created: https://github.com/vyos/vyatta-op/pull/65

It seems to exist for current Debian 12.1 (bookworm) so I think it should be a relativily simple task to add that if not already existing:

Sounds almost related to this longrunning shitshow between FRR and the Linux kernel:

I tried digging through google if somebody else have encountered the same but I couldnt find any obvious hints (except for the zebra nexthop-group keep 1 already mentioned).

I added a comment to https://github.com/FRRouting/frr/issues/12239 so hopefully there might be some other commands or stuff to do other than the debug-commands to hunt this thing down.

And the logs looks the same as in your original post?

Dont count on it - the way things works on internet is that there are alot of people complaining at stuff but very few who does something about it :-)

If it crashes it should be reported upstream to kernel.org (and the maintainer for the r8169 driver) since VyOS is using the latest Linux Kernel LTS (current version 6.1.43 as of writing):

There is a bugzilla opened for this issue: https://bugzilla.netfilter.org/show_bug.cgi?id=1697

I can confirm that updating blacklist now is vrf aware and functional:

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

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

Added task https://vyos.dev/T5440 to fix the issue of preconfig-script doesnt show up in /config/scripts after system upgrade (add system image).

I need some help with this one.

It seems happy for now:

Note, if mgmtd is of no use in VyOS then the preferred is to have it disabled all together (after updating daemons.tmpl in case it gets enabled in future).

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

Note also that 1.4 rolling as of today (3rd aug) uses FRR 9.0 (previously I think 8.5.4 were used or something like that).

Note that you had an "s" too much in your command.

Found that the defaults in daemons-file are set by VyOS in /usr/share/vyos/templates/frr/daemons.frr.tmpl

Done!

Just to sync this task to PR 2118:

As mentioned in https://vyos.dev/T5419 the offloading should not only apply for NAT.

This particular case was resolved by adding:

I added this comment to PR 2118:

A not too uncommon workaround for this is to disable the lease-file (if possible) and give out leases based on option82 information instead.

Is this a limit of wireguard?

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?

Tested and verified as described in the pull request:

Oh, and the reason for why using chrony instead of ntpsec is?

Why this limit?

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

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

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:

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

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