PR for current: https://github.com/vyos/vyos-cloud-init/pull/78

PR for 1.4: https://github.com/vyos/vyos-1x/pull/3806

In T6545#194997, @SrividyaA wrote:

@Viacheslav, For site-to-site or server/client mode, when used cipher option as none then also issue is noticed. When you commit, it gives this warning:

vyos@vyos# set int openvpn vtun1 encryption cipher none
[edit]
vyos@vyos# commit
Warning: "encryption none" was specified!
No encryption will be performed and data is transmitted in plain text over the network!

Logs:

Jul 10 14:51:39 openvpn-vtun1[12357]: Cipher NONE not supported

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

@Viacheslav, For site-to-site or server/client mode, when used cipher option as none then also issue is noticed. When you commit, it gives this warning:

In T6563#194972, @Viacheslav wrote:

Any idea for CLI?

Any idea for CLI?

Since loopback and dummy are fundamentally different in Linux, trying to pretend they are not would be misleading rather than helpful. Unless anything changes in the kernel, we should keep things as is.

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

Recovering gracefully and logging an error is a simple fix, and will be committed in the interim while the larger issue is addressed: namely, when running under vyos-configd, a ConfigError in a called dependency script should elicit a commit error in the originating config session. Here, however, we confront again the constraints of operating under the legacy commit algorithm. To address the matter, we will implement a partial solution to T5731 so as to catch verification errors in the (first instance of) sequential processing of the priority queue and cache the data for final processing of the activation stages (generate/apply); errors in the latter stages, as less common, will be logged. The sketch provided summarizes a design that balances the needs of early and correct (verify stage) error reporting with removing redundancy overhead when running under configd.

There are two possible places where encrypted DNS support might be desired in a standard setup where VyOS is hosting a local resolver/recursor:

After spending more time handling VRFs within VyOS the answer from @Viacheslav is best

In T6211#194799, @stephenmcmahon wrote:

In T6211#189615, @Viacheslav wrote:

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'

In T6211#189615, @Viacheslav wrote:

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.

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