As far as I can tell the test will always error if the remote matches and neither source-interface and source-address are configured differently, including the case where they're both blank (source-interface == None on both tunnels triggers this particular case).

https://github.com/vyos/vyos-workflow-test-temp/pull/5
Validated.

Only recently moved from 1.3 to 1.5 and noticed rollback-soft immediately (great stuff), the completion message was annoying me too.

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

I've just been picking at this one tonight because it's close to some areas of interest (DMVPNs in VRFs), so hopefully this input is useful and appropriate:

yes, that would be a very good solution/implementation

Is there already something in the works? As for now, there seem to be issues with regdom settings in VyOS 1.5 anyways (see https://vyos.dev/T6320 "Quirks and Workarounds").

Probably the best way will be moving the config to the vrf section (not implemented)
For example:

set vrf name foo service dhcp-server shared-network-name eth1 option default-router '192.168.1.1'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 lease '300'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 range default start '192.168.1.10'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 range default stop '192.168.1.100'
set vrf name foo service dhcp-server shared-network-name eth1 subnet 192.168.1.0/24 subnet-id '1'

And start several instances, each with its configuration.

you have to adapt a few more things, if absolutely necessary it also works with several VRFs - but it is very ugly...

FYI: The configuration is valid and works. It just fails during boot.

The similar task for redirect T260

I assume that workaround would only work for a single VRF or can one do something like this?

The following can be configured as a quick and dirty workaround:

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

I am already working on the PR :)

Resolved, merged PR: https://github.com/vyos/vyos-1x/pull/3508

Difficulty changed to normal to consider one subtlety of xml cache, and add POC for use in (a later version of) the strip-private filter. POC below; some subset of commits may be added to 1.5:
https://github.com/vyos/vyos-1x/compare/current...jestabro:example-property-secret

The idea is feasible for parameters with constraints (like number ranges) defined in the XML, but there are many other cases where human input is necessary. We could give the tool a set of parameters to randomly generate, or a half-complete config with slots to fill in with random values. Worst case, we'd discover new constraints for more rigid templates; best case, we'd have a proper tool for generating corner cases for smoke tests and fuzzing.

https://github.com/vyos/vyos-1x/pull/3510

https://github.com/vyos/vyos-build/pull/634 Merged

Please mark this as resolved

Follow up, I was able to make nat.py throw the error below.

@Viacheslav, same behaviour exists for epa3, I numbered mine 999 so as not to interfere with existing rules.