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.

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

It is not VyOS bug

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.