Why must the operstate be up? I't rather check if the tunnel is configured (/opt/vyatta/etc/openvpn/status/vtun1.something) exists and then run the commands.
Thus if the tunnel is down due to remote end beeing offline it would not report it as operstate is down (if operstate is properly implemented in OpenVPN)

@jjakob if what you say is correct then the solution should look like. I can not test it tho (simply as I do not know how to setup OpenVPN and have no lab to make it work).

Successfully tested on 1.2.5-epa2 and 1.3-rolling-202003310117

Without source ip address from local prefix strongswan can't create route in table 220. I'm not sure that we need to check and decline a commit. But we can show warning message.
Interfaces on boot have more priority and it can guarantee that if in router exist ip address from local prefix, strongswan will create the route,
When interface configured after IPSec, need run restart vpn for add routes.
I propose to add the following code to https://github.com/vyos/vyatta-cfg-vpn/blob/current/scripts/vpn-config.pl#L670

my $check_local_route = qx(ip route show table 254 $ocalsubnet_object);
if (!$check_local_route){
    print "Warning: local prefix $localsubnet_object specified for peer \"$peer\"\n";
    print "is not configured on any interfaces\n";
}

@c-po do you have any updates?

+1, I'd also like if all failed commits were stored in a permanent log somewhere to make debugging easier, I can't find one right now.

The file exists on my system (1.3-rolling-202003291001):

-rw------- 1 root root 377 Mar 31 11:44 /opt/vyatta/etc/openvpn/status/vtun0.status

and show openvpn server works:

vyos@rt-home:~$ show openvpn server

I vote for this as well. I have a lot of addresses I need to add to a nat source address so I need to create one rule per IP. Because I have a specific rule numbering scheme, I'm running out of space in it so I had to break the scheme. The ability to use groups in nat source and destination addresses would greatly help.

Thank you for the assignment but I have not looked at or touched the OpenVPN code (and never used OpenVPN myself).
This issue with the op_mode, not config mode, so so it must have been there for a while.
I could change the code to check that the file exist, and prevent this fault but I am not sure it would be the right thing todo.

While you're looking at it, can you try to move it to a systemd service? I opened a task for discussion: T2185

I think I agree: at commit time, user's CLI edit level is irrelevant and should have no effect on the script behaviour.

If this is a duplicate of something, go ahead and close it

PR283 should fix this.

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

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

In IPv6 the next-hop interface is simply called interface to mimic the default IPv6 behavior of the Vyatta code.

Already fixed via https://github.com/vyos/vyos-1x/commit/3a46ad00f55873e1372f24a01f3c2698e6568623

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

This check interferes with the commit.
https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/interfaces-vxlan.py#L163

I created a network diagram for "l2vpn evpn" implementation.
I used this instruction vxlan-bgp-vpn