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.

I don't get this thing.
You can use any number that you want.
Could you explain what exactly Is wrong and why you can't use your own declared numbers?

Does it do what you want?

vyos@r14# set system frr snmp 
Possible completions:
   bgpd                 BGP
   isisd                IS-IS
   ldpd                 LDP
   ospf6d               OSPFv3
   ospfd                OSPFv2
   ripd                 RIP
   zebra                Zebra (IP routing manager)

For example

vyos@r14:~$ show conf com | match ldp
set system frr snmp ldpd
vyos@r14:~$ 
vyos@r14:~$ ps ax | grep ldp
   1006 ?        S<s    0:00 /usr/lib/frr/watchfrr -d -F traditional zebra mgmtd bgpd ripd ripngd ospfd ospf6d isisd babeld ldpd eigrpd staticd bfdd
   1075 ?        S<     0:00 /usr/lib/frr/ldpd -L -u frr -g frr
   1076 ?        S<     0:00 /usr/lib/frr/ldpd -E -u frr -g frr
   1079 ?        S<s    0:00 /usr/lib/frr/ldpd -d -F traditional --daemon -A 127.0.0.1 -M snmp
   3124 pts/0

I don't get which exact issue with VRRP
but if you have an issue, please add a separate task.
Provide sudo nft list ruleset before and after the bug version. Bug with VRRP definitely not clear for now.

Intuitively, if a user explicitly enables a feature with inherent management traffic (BGP, VRRP); their expectation would be for the feature they just enabled to work. In my opinion, the current behavior violates principle of least surprise. It also seems different from 1.3 (and earlier 1.4 behavior?)

I've tested our last rolling-realase , it's working as expected :

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

I would disagree with a hidden ruleset.

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

This delay is not only present in latest version. Huge firewall (and not only firewall) config leads to more processing while committing changes.
Bare in mind that for every firewall config command, python scripts are invoked for sanity checks and for config generation.
If direct nft commands are used, then all this scripts are not called.

It seems that only one address could be set

--publish, -p=[[ip:][hostPort]:]containerPort[/protocol]

https://docs.podman.io/en/latest/markdown/podman-create.1.html#publish-p-port

This PR will be reintroduced following completion of T5500.