Yes, this can be marked as completed.

Since it's an FRR behavior detail, there's nothing we can do about that. But we probably should disallow trying to match both IPv4 and IPv6 options in the same rule.

This is probably resolved already in 1.4 and 1.5, but we need to confirm that.

I am not able to reproduce this, and conjecturally it was fixed in kernel version updates subsequent to the report. Compare the fix for Equuleus in:
https://vyos.dev/T5684
and the kernel commit mentioned therein:
https://github.com/torvalds/linux/commit/9dcc38e2813e0cd3b195940c98b181ce6ede8f20

It's been multiple StrongSWAN updates since then and no additional info, but if the issue reappears, feel free to reopen.

If the issue is still reproducible, feel free to reopen.

We made successful ARM64 builds since then, but if the issue reappears, feel free to reopen.

Done

vyos@r4# set high-availability virtual-server serv1 forward-method 
Possible completions:
   direct               Direct routing
   nat                  NAT (default)
   tunnel               Tunneling

@jack9603301 a concept for translation to other languages is currently in process.
It will be done with https://localazy.com/
a how-to will be announced in a blog post, which is is still in draft.

Closing this until we have reproducing steps.

We have the add command now.

If the issue is still reproducible, feel free to reopen.

Closing this as resolved, please re-open if any further issues found.

Since the original vyos-vm-images is deprecated, I suppose we should close this for now.

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

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

Well-known behavior when you use VTI interfaces you have to use set vpn ipsec options disable-route-autoinstall otherwise you can get any unexpected things.

Kea doesn't have that issue, and in 1.5 rolling release builds, static leases are already displayed in show dhcp server leases. But in ISC DHCPd, which is unmaintained, I'm not sure if we should switch from the tried and proved static leases to anything else.

@jack9603301 Feel free to create a PR as do usually do for documentation, the Task is not required.
For example https://github.com/vyos/vyos-documentation/pull/1229

Are we going to just let EVPN be the L2VPN technology of choice and not go down the VPWS/VPLS route for L2VPN? EVPN is the future anyway, so going and adding VPWS/VPLS is kind of doing legacy work.

No longer applicable now that XDP is phased out.

We use the netavark plugin for the containers, which fixes this.

set container name alp01 image 'alpine'
set container name alp01 network NET01
set container network NET01 prefix '100.64.0.0/24'

Fixed in https://github.com/vyos/vyos-vm-images/commit/090e5367dc6df9b49c037e0b60f7adfafdf54a53

@fernando Thanks!

i've re-checked with the new image from GCP and new cloud-init version , it seems to be working as expexted :

The kernel is not supporting pseudowire/VPLS now
this patch was never merged into the kernel

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

No, installing the miniupnpd_functions.sh file does not correct the problem.

Another bug it that /config/upnp.leases is hardcoded, but there is no script who creates it https://github.com/vyos/vyos-1x/blob/aebb458262072457c6a3840d1b17031fbd780eca/data/templates/firewall/upnpd.conf.j2#L128

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

Will it work if you manually download the functions? https://github.com/miniupnp/miniupnp/blob/miniupnpd_2_3_1/miniupnpd/netfilter_nft/scripts/miniupnpd_functions.sh

OK, a little digging around in the grub configs led me to a "workaround" solution for the serial console problem after the machine is booted.

Can confirm this is exactly the same in 1.4 rolling (as of Jan 09). Same errors. The miniupnpd daemon receives the request (for either a UPnP, NAT-PMP, or PCP port mapping) and then reports the errors @simplysoft reports in the description.