So how are all the other helpers added to the ruleset if not dynamically?

Then how come these helpers are always enabled as pointed out at https://vyos.dev/T5080#149232 ?

How come these helpers (pointed out by @saintclairpcarvalho but also )https://vyos.dev/T5479) are always enabled?

Found some anomalies regarding show firewall command (I assume related to the refactoring) which I have reported in https://vyos.dev/T5513

The refactored firewall frontend uses rule numbers as described in: https://docs.vyos.io/en/latest/configuration/firewall/general.html#firewall-rules

PR created: https://github.com/vyos/vyos-build/pull/381

Using VyOS 1.4-rolling-202308250021.

The file list_ntp_servers.sh is nowhere to be found in VyOS 1.4-rolling-202308250021:

I assume this will fix by itself if you build your own 1.3.3 LTS from sources today since 1.3.3 LTS was released in june 2023:

I guess this can be closed by reason "Not a bug" or similar?

Isnt this resolved now by the commit of @c-po at 2 aug?

Using VyOS 1.4-rolling-202308250021 the option "config-trap" is no longer to be found and the remains of config-trap causing commit to crash with a traceback have also been fixed:

Confirmed fixed in VyOS 1.4-rolling-202308250021:

@rherold Well thats how it is today with default-action:accept where ALL ports are open to ALL services on ALL interfaces.

Related: https://vyos.dev/T5471

Yes but if you have more than a few rules its shitty to have to do this manually.

Then perhaps add it as an global-option or similar to make life easier for the admin to not having to dig into how each service should have the firewall configured in order to make it work properly?

@giga1699 Again, if I as an administrator enable BGP and configure it with "neighbor x.x.x.x" I expect this to work without having to setting up multiple additional firewall rules on my own. Same goes with if I enable DHCP-server on the VyOS - I expect it to work.

PR created (which replaces previous PR 378): https://github.com/vyos/vyos-build/pull/379

PR created: https://github.com/vyos/vyos-build/pull/378

Include VyOS functions

source /opt/vyatta/etc/functions/script-template

Verified being fixed in VyOS 1.4-rolling-202308230020.

So where should this be filed instead?

Related: https://vyos.dev/T5388 (Something is fishy with commit and boot times when more than a few hundred static routes are being used).

The following is for example made up by migration:

So the bug is that "boot=live" is being used when installing VyOS to a harddrive?

@giga1699 There are already plenty of hidden stuff going on if you take a look at the output of nft -s list ruleset.

Yes, that output seems to have the snmp module (which exists in /usr/lib/x86_64-linux-gnu/frr/modules/) loaded.

Comparing with other vendors thats what you use the ACL for.

A dirty workaround would be to include a "hidden" (as in it exists in nft but not displayed in the vyos-config itself) CoPP table which includes the port(s) needed for:

As seen on slack and I think on the forum.

Perhaps same workaround as firewalld is implementing through option "IPv6_rpfilter=yes" could be implemented in VyOS (both uses nft)?

Possibly the fib statement can be used through nft:

Looks like you would need some more extensive checking of that partition.

I have created this task regarding the fsck issues (fsck does not run during boot): https://vyos.dev/T5498

In PR 2152:

Works for me without errors but I currently only have an empty ruleset:

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?