We need to check if it's still relevant and decide if it declare it WONTFIX.

Builds of 1.3 were made successfully since then, but if the issue reappears, feel free to reopen.

Works as expected now — prevented at the set stage.

That would be nice, but it will require a very different approach — there's no quick fix.

The PR was rejected but the task was never closed, closing now.

Looks more like a support request to me. If any specific bug report or feature request turns up about this, feel free to create it.

If it reappears, feel free to reopen.

If the issue reappaers and you find the reproducing steps, feel free to reopen.

Maybe it's working with Kea already in 1.5?

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'