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

Tested as working in: 1.5-rolling-202405240020

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

Is this meant to be possible this way?

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).

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

yes, that would be a very good solution/implementation

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...

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

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.

@Viacheslav
Happy to dig into this if can assign it to me.

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

Same issue applies to NAT66, too

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

In T3493#189273, @Viacheslav wrote:

Does 1.5 has the same bug?

Does 1.5 has the same bug?

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