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.

I did start writing support for this but didn't have time to build and test it at the time. If anyone wants to test it out: https://github.com/sarthurdev/vyos-1x/commit/9199b75d75ceea3b7d49f0e3d71a19175b7b1326

There's request for fib matcher: https://vyos.dev/T5119
It would be useful if you could propose cli design for this feature in that task, so we can discuss about it and then work on adding it

PR: https://github.com/vyos/vyos-build/pull/377

Until the other maintainers share their ideas and thoughts I would like to add some context about FreeIPA and Active Directory, as I have the impression, that the difference between FreeIPA and Active Dirctory is not completely clear.

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

The short story:

I disagree with that. Cause only why bgp is running, we don't need the port to be reachable on all interfaces or for all source IP's.

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:

It's me. I'm User! Happy to provide before (1.4-rolling-202308060317) and after (1.4-rolling-202308180646) VyOS configs and nft dumps for analysis. I can reliable reproduce/correct the issue by switching between those two images.

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:

today I want test how fast firewall rules loading and changing in vyos performed. I took an vyos-1.4-rolling-202308180646-amd64.iso boot it as kvm guest.
Then I added some rules with:

Looks like the Problem still exist in 1.4. Are there any plans?

Nope, scrap the above. (Even though it would not surprise me if systemd would be able to perform such tasks in initramfs or else where.)

My guess is that a whole bunch of systemd-things are missing inside initramfs.
For example systemd-fsck-root.service has Before=local-fs.target shutdown.target & ConditionPathIsReadWrite=!/ which (to me) suggests it should be ran from inside initramfs, before your root partition is mounted.

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

I ran what you suggested, but it still shows wrong block/inode count right after boot.

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

As I understabd FreeIPA is an alternative to ActiveDirectory? And SSSD should support authentication via LDAP only if the backend is AD.

I managed to enter initramfs on the machine running in a VM by appending break to grub. From there I manually ran a fs check, which didn't show any issues.

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

PR for 1.3 https://github.com/vyos/vyos-1x/pull/2158

Both attached files seem to be downloadable (but now viewable in browser) from the download-link in the upper right corner after clicking a file.

Thank you for taking a look on the PR.

In PR 2152:

Adding Kerberos to a router is overkill in my opinion. I'd agree on adding LDAP(s) auth support via sssd of course, but Kerberos is simply a bit beyond the scope.