After a few hours of digging I do think this request would be very similar to geoip, only ipv4, and ipv6 groups would be required per list.

PR adds groups to NAT: https://github.com/vyos/vyos-1x/pull/1633

Reopened, as this was never backported to 1.3; set for 1.3.3.

I didn't look deep into the nft groups, so I wasn't sure if we could mix ipv4/6 and addresses and networks, if we can then I agree one group would be best, though I'm sure ipv4/6 would still need to separate but checking each line for : makes that task super easy and fast.

From my point of fiew, looks interesting.
The proposed structure and behaviour doesn't look that different than what is currently in geoip filtering: external URLs with data, and sync from time to time.

The enhanced linux-cp plugin (from IPng) is since 21.06 an official part of VPP, so the integration should be simple:
https://vpp.flirble.org/master/aboutvpp/releasenotes/v21.06.html#linux-control-plane-plugin-linux-cp

A patch to the WIDE DHCPv6 client seems to be sufficient to resolve this issue with respect to the way VyOS currently uses the daemon (one daemon per configured interface), PRs below:

Sure, it is fully compatible with 1.3. If no problems are found after the changes in 1.4 it must be backported.

Requires rewriting function show to python-systemd

on nightly build nftables v1.0.5 and kernel 5.15.76

As a first step, we need a wrapper script to control the start, stop and restart of socat, because socat sometimes exits automatically

As a first step, we need a wrapper script to control the start, stop and restart of socat, because socat sometimes exits automatically

I created a PR to solve this specific issue (and some more related to this): https://github.com/vyos/vyos-1x/pull/1637

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

normally, when I want to make an empty-base config, I save config.boot another place. So I load it when I need to restart the configuration. I was thinking that we can make something like it by cli, it should be saved in the first config.boot file and restored.

Maybe a simplified and interactive cli, as when adding new image? So user can decide what to do with other images and containers.

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

Adds firewall node rule N source/destination fqdn domain.com for single domains per rule and refactors resolver daemon.

In addition to the configuration, you also need to reset all logs/custom scripts and boot from the base image.
What will be if you have several images? Should we delete all other images?
What will be if you have container images? Should we delete them?
And there are many other nuances.

@Arc771
Could you provide an example of how to generate the required keys? We will test it.
But It should be a separate task

So the original task means that we don't have new CLI options in login keys
Missing sk-ssh-ed25519

vyos@r14# set system login user foo authentication public-keys foo type 
Possible completions:
   ssh-dss              None
   ssh-rsa              None
   ecdsa-sha2-nistp256  None
   ecdsa-sha2-nistp384  None
   ssh-ed25519          None
   ecdsa-sha2-nistp521

Seems to be not fully functional

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

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

Done: https://github.com/vyos/vyos-1x/pull/1630

@zsdc could we backport it to 1.3?

Backport for VyOS 1.3.3 https://github.com/vyos/vyos-1x/pull/1629

Good point, I'll try and look into this and see if it can be handled everywhere the new PKI nodes are used.