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:

Closing this task because better way to match multiple interfaces in firewall rules would be using interface groups.

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.

Missing vrrp cli version in last line in config.boot file:

@Apachez I would also not want this. Example bgp on eth0 with one peer. I would not like to see to have the bgp port open for all source ips, only for the configured peers and not more.
To make it better to manage for the admins I would like to see a syntax like in junos:

PR to fix indentation: https://github.com/vyos/vyos-1x/pull/2171

PR f or 1.3.4 https://github.com/vyos/vyos-1x/pull/2168

@zsdc Can we backport it to 1.3?

Can also confirm this on multiple nodes with said config, running post-firewall-refactor-builds.

Related: https://vyos.dev/T5471

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

Will be fixed in https://vyos.dev/T5506

In my internal tests, it works even without listen-address

set container name c1 image 'docker.io/ealen/echo-server'
set container name c1 network NET01
set container name c1 port web destination '80'
set container name c1 port web source '8080'
set container network NET01 prefix '10.0.0.0/24'
set container network NET01 prefix '2001:db8:2222::/64'
set interfaces dummy dum0 address '2001:db8:1111::1/64'
set interfaces dummy dum0 address '203.0.113.1/32'

@Apachez, I got your point. The thing is, we don't have cisco-like CLI and can modify any seq rule.
It possibly could be from op-mode (not sure) because otherwise, you get resequence per each commit. That is definitely wrong.

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

If it is only per migration, you can change it in migration or rewrite the rules once.

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?

The firewall will not be autoconfigured by bgpd or something else. We are not going to do it.

@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

No, setting boot=local will run a completely different set of ("vanilla") boot-scripts, which (i guess) will not set up the special mounts that VyOS requires, and you will end up in initramfs with an error.

Thanks for adding the "listen-address" configuration option, unfortunately that alone may not be enough to make ipv6 services work on rootful podman. I didn't realize this since I primarily use rootless podman on my Fedora and SuSE machines or docker on the server side.

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

@jworrell I agree that if an administrator turns on a service it should be functional. If no firewall is configured, and a security ruleset isn't required for the use case, there's no issue with something being in place that allows that traffic for extra comfort. However, if security rules are in place it should be the burden of the administrator to define how that management traffic should be handled. This would be consistent with previous versions of VyOS that if you applied a default-deny to the local direction of an interface, you would need to specify any management traffic for the interface explicitly. By introducing hidden allows, this would violate the principle of least surprise that you mentioned.

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.