Getting link-local addresses to work would probably be very low-priority, but I did run into an extremely niche case where I wanted to do that. It's not the type of situation that would happen in a production environment, but I was running VyOS on a computer tethered via ethernet to an Android-based phone, and I wanted to connect to a wireguard peer running on the phone. Modern version of Android randomize the IPv4 address of their tethered interface on each reboot, but their link-local IPv6 address remains the same, making it more convenient to use it.

Link-local addresses with %ethX are not accepted in any protocols/peers/etc. A few services are allowed to set them as listen like ssh/dns at the moment.
Is there a real use case why you need it on wireguard interfaces?

It generates by openvpn, maybe something new in the new OpenVPN version
So I see only one option - add mode server-bridge

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

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

@hensur I'm glad you reimplemented this feature. Come on

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

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

See comment in T4164: is working now.

See comment in T4164: my config runs through easily now.

@sdev this (and the other fixes) look promising: after upgrading to the latest rolling release from 13.1.2022, both the example provided in the ticket as well as my config (a copy of my production setup with rules covering PBR, empty groups, references to "defines" in PBR rules) ran through easily. My production config created no errors when loading the config after the update.

Thanks for the report, working on the fix now.

In T4164#116547, @mTx87 wrote:

seems like policy based routing not working.

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

moved my comment to a new bug request to keep this one here clean.

T3741

Any updates? No one?

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

but wasn't necessary on VyOS 1.4-rolling-202109280217
so I guess changes to FRR that are the cause right?

Add neighbors to their proper afi:

• Incorrect custom scripts data if used tunX interfaces
  • Allow inputs.ethtool only on Ethernet interfaces, by default it tries to get statistics from each interface, template

Jan 12 19:37:30 r11-roll telegraf[7703]: 2022-01-12T17:37:30Z E! [inputs.ethtool] Error in plugin: dum0 stats: operation not supported
Jan 12 19:37:30 r11-roll telegraf[7703]: 2022-01-12T17:37:30Z E! [inputs.ethtool] Error in plugin: gretap0 driver: operation not supported
Jan 12 19:37:30 r11-roll telegraf[7703]: 2022-01-12T17:37:30Z E! [inputs.ethtool] Error in plugin: gre0 driver: operation not supported
Jan 12 19:37:30 r11-roll telegraf[7703]: 2022-01-12T17:37:30Z E! [inputs.ethtool] Error in plugin: erspan0 driver: operation not supported

Incorrect custom scripts data if used 'tun' interface
https://github.com/vyos/vyos-1x/blob/current/src/etc/telegraf/custom_scripts/show_interfaces_input_filter.py

PR https://github.com/vyos/vyatta-op-vpn/pull/32

yes, you are right:

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

PR:
https://github.com/vyos/vyatta-cfg-firewall/pull/29/commits

Forgot that my PR for WLB was still a draft. That the jump does seem to be created properly with this PR in place.

That build at 08:11 UTC was a couple of hours before the commit was merged: https://github.com/vyos/vyos-1x/commit/f97144259335102c3d96b232cbb0af4970120d62

yes , i'm using this version :

PR https://github.com/vyos/vyos-opennhrp/pull/3

Seems to be working on my latest build?

I've checked with this new build , it works with validator ranges/port :

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