Extra checks are needed not only when attaching a policy route to an interface, but also when attaching firewall.
For example:

vyos@vyos# set firewall name FOO rule 10 action accept 
[edit]
vyos@vyos# set firewall name FOO rule 10 destination group address-group NOAG
[edit]
vyos@vyos# commit

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

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

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

Fix Regex for addresses and python ckecks https://github.com/vyos/vyos-1x/pull/1354

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

@panachoi There is a task for groups T4147

Indeed, I figured that out. I also found that my openvpn config was not migrated properly (T3642?); all of the tls configuration stuff (previously kept under /config/auth somewhere) was gone. After doing run import pki for all of the necessary bits it was able at least to commit openvpn properly.

Same as Viacheslav. No issues on my tests in Ubuntu.

1. Some domains can't be added, for example dns.google

vyos@r12# set firewall group domain-group DOMAINS address dns.google

Fix smoketest https://github.com/vyos/vyos-1x/pull/1352

Yes. New 1.4 has more restricted checks on addresses and networks.
Actually, if you are using /22, the correct network for this case is 192.168.44.0/22.
You can use this online tool for checking ipv4 networks and subnets.

Sorry its taken me so long to follow up on this

This configuration commits without errors. Can the report be closed?

In T4460#124345, @Viacheslav wrote:

From provided log syntax error in config string 6
‘holding-time 300’

But yes “ cisco-authentication” shouldn’t be without values

From provided log syntax error in config string 6
‘holding-time 300’

Don't have any issues with Ubuntu

set interfaces dummy dum0 address '192.0.2.1/32'
set interfaces dummy dum4 address '203.0.113.1/24'
set interfaces ethernet eth0 address '192.168.122.11/24'
set interfaces ethernet eth0 description 'WAN'
set vpn ipsec ipsec-interfaces interface 'eth0'
set vpn l2tp remote-access authentication local-users username test password 'test'
set vpn l2tp remote-access authentication mode 'local'
set vpn l2tp remote-access client-ip-pool start '192.168.255.2'
set vpn l2tp remote-access client-ip-pool stop '192.168.255.254'
set vpn l2tp remote-access ipsec-settings authentication mode 'pre-shared-secret'
set vpn l2tp remote-access ipsec-settings authentication pre-shared-secret 'secret'
set vpn l2tp remote-access outside-address '192.0.2.1'

Added more options. PR https://github.com/vyos/vyos-1x/pull/1350

@NikolayP , Looks like MTU and MPPE issue. Stoping daemon does not related to this I think.

I already merged your XML definition ;)

I once made XML, it might come in handy

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

Ultimately I moved my physical connection from port eth0 to eth4, and configured eth4 with the same config as was on eth0. Once I did that everything was stable and has been stable for days (nearly a week now). I'm not sure what could be causing an interface to work for an amount of time, then as if on-cue stop forwarding packets.

Not sure if this is relevant to the task.
But once when shutting down a VM with VyOS 1.3.1-S1, it took a long time to shut down:

Should I make improvements to the remaining revisions in the PR?

Sorry I just saw it now, I'll test it. But because of limited conditions, I may test in the future, please forgive me

In T3435#115394, @n.fort wrote:

Error still present on VyOS 1.4-rolling-202201020317

vyos@vyos:~$ show nat source rules 
Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/show_nat_rules.py", line 114, in <module>
    print(format_nat_rule.format(rule, srcdests[0], tran_addr, interface))
IndexError: list index out of range
Rule       Source                                             Translation                                        Outbound Interface
----       ------                                             -----------                                        ------------------
vyos@vyos:~$ show ver

Version:          VyOS 1.4-rolling-202201020317
Release train:    sagitta

Nat config in this example:

vyos@vyos:~$ show config comm | grep nat
set nat source rule 10 description 'Masquerade to NAT'
set nat source rule 10 outbound-interface 'eth0'
set nat source rule 10 translation address 'masquerade'

@m.korobeinikov I believe that I already posted this some time ago, but just in case...
Not all combinations of DPD and close-action are safe. Actually, most of them sooner or later will lead to issues with IPSec. So, I created the next scheme. It is from 2020, so I will not say that nothing was changed from that time, however, it shows well how careful you should be while configuring IPSec. On the scheme, you can see the only safe configuration of the close-action option, depending on how the peer is configured, but the same logic can be applied to DPD.

PR https://github.com/vyos/vyos-build/pull/240
disable owamp|twamp.service by default

@SrividyaA will be present in the next rolling release

PR for the current https://github.com/vyos/vyos-1x/pull/1346

In T973#124168, @superq wrote:

I wouldn't call telegraf a very good option. It does a very bad job of producing Prometheus metrics.

For Debian11 requires pkg "libpam-tacplus" that is not available https://github.com/kravietz/pam_tacplus/issues/180

I wouldn't call telegraf a very good option. It does a very bad job of producing Prometheus metrics.

Prometheus-client already in 1.4
https://docs.vyos.io/en/latest/configuration/service/monitoring.html#prometheus-client

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