In T6281#185620, @c-po wrote:

You probably should get the wireguard interface running in your default VRF first and see if traffic properly passes - once that's working for oyu you can move it into a VRF. Please not only the decrypted side of the WireGuard interface will reside in the VRF. The side passing encrypted packets ALWAYS is in the default VRF (Linux Kernel)

Thanks for the hints, that makes sense. Let's see how that can be implemented :)

For added service when typing just:

You probably should get the wireguard interface running in your default VRF first and see if traffic properly passes - once that's working for oyu you can move it into a VRF. Please not only the decrypted side of the WireGuard interface will reside in the VRF. The side passing encrypted packets ALWAYS is in the default VRF (Linux Kernel)

You would still be limited to not be able to use " as part of your password.

There should also be migration scripts, as CLI will be changed.

Proposal:

set system config-management commit-archive uri "stor01z-cs.int.trae32566.org/cr01b-vyos"
set system config-management commit-archive scheme "sftp"
set system config-management commit-archive username "cr01b"
set system config-management commit-archive password "$T3$TP@$$W0^%"

We could improve it by breaking up configuration, having the user providing a URI, Protocol and optional username/password as separate values.
Then we can properly encode username/password. This would also give more flexibility how username/password are handled and passed on.

In both cases it is kind of an user error, the password would have to be properly url encoded if provided in one (@ should be %40 in an URI, a ! should be %21).

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

set service config-sync secondary address '192.168.122.11'
set service config-sync secondary port '8443'

Documentation does not require a task on the phabricator.
Thanks.

Migration needed for listen-address when upgrading from isc-dhcp to kea dhcp (1.4 to 1.5)

PR for 1.5: https://github.com/vyos/vyos-build/pull/579

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

@Zen3515, any idea for regex?

Works as expected in VyOS 1.5-rolling-202404290019 and VyOS 1.4-stable-202404300309 and VyOS 1.3-stable-202404300508

vyos@r1-right:~$ cat /etc/resolv.conf 
### Autogenerated by VyOS ###
### Do not edit, your changes will get overwritten ###

1.2 is EOL

In T6281#185394, @c-po wrote:

Please note that the Wireguard tunnel itself is sourced from the default VRF. Only the "inner side" of the tunnel runs in VRF wan.

There is no possibility to source the wireguard interface from

• Another VRf
• A discrete source IP
• A discrete source interface

This can only be handled by applying fwmark values and policy based routing - this is a WireGuard design thing.

Please note that the Wireguard tunnel itself is sourced from the default VRF. Only the "inner side" of the tunnel runs in VRF wan.

Running into this issue on VyOS 1.5-rolling-202404280021

set protocols static route xxx.xxx.74.149/32 dhcp-interface eth1.999

It would be useful for 1.4 as well, to be able to rebuild the LTS with local patches to some packages but otherwise unmodified, for example to make it easier to test bug fixes in a single package (such as accel-ppp https://vyos.dev/T4600 ) without much risk to introduce new bugs.

I can (carefully) say it's probably fixed in 1.3.x with newer FRR (compared to 1.2.x in the original report) - I've moved the two PPPoE servers to the same two boxes running BGP (still using OSPF to redistribute routes, at few hundreds of them scalability is probably not an issue yet that would require BGP) and they don't seem to crash anymore.
Not tested in 1.4.x yet - I may test it some time after the 1.4 final release, if I will still be able to get it.

If this ever becomes a thing, support for directly connected routes (ie. PPPoE) would be great as well.