How does e.g. syslog-ng behave?

This is a typo in the documentation. In the real system, the facility is called security, but it is deprecated at least from the 2004 year.
The problem that I see in names is that it seems that different systems and software may use slightly different names for facilities. So, could be a good idea to do the two things:

• check existing and add missing facility names in CLI
• in the actual configuration transparently convert facilities to numeric representation to avoid software issues (like deprecated security facility in rsyslog).

@Viacheslav this ticket can be closed.

I closed it. Can't reproduce it.
Re-open it if necessary. Just attach your vpn configuration.

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

Wireguard has its own fwmark setting, such as:

@fetzerms The feature "policy local-route" in the 1.3/1.4 only.

Thanks for the info. I think (indeed) that *might* work for wireguard. But never the less, it would be cool to have the possibility to route by fwmark.

We only have source routing now:

@Viacheslav it is reproducible in 1.2.7

vyos@vyos:~$ touch file1
vyos@vyos:~$ touch file2
vyos@vyos:~$ touch file3
vyos@vyos:~$ ls
file1  file2  file3
vyos@vyos:~$ reset vpn remote-access user 
Possible completions:
  file1         Terminate specified user's current remote access VPN session(s)
  file2
  file3

For RPS, we maybe can adapt https://github.com/bhuanand/rps-rfs-configuration to VyOS?

@Harliff Try 1.2.7/1.3 it was fixed with commit https://github.com/vyos/vyos-build/pull/138/files#diff-c7d29a506307d9cf8d86c3cd3f65ca4e4058ea442cacdf9a89d2485b56c7417aR67
T2061

I've not checked later versions. Maybe it was already fixed on 1.2.7 or 1.3/1.4 ?

Approved on 1.2.7 and 1.3/1.4

I opened a new ticket for an error that is now occurring while building the iso in the docker container.

Just tried to compile the ISO image but I got an other error:

At least on simple tests, this modification seems to work.
I have tested on version 1.3, first configuring dhcp server for both addresses: for the one that was defined first, and one for the las IP address defined (of course, one instance of dhcp-server running at a time).
If this needs more testes, let me know what I can do for you.

Should be fixed with commit https://github.com/vyos/vyos-build/commit/7905f0d5715bb8da158d09734ba78dc28b2fd4e1

@n.fort You can try to replace True with False there (1.3 and 1.4). But it needs more tests. In some cases, it was some bugs with the DHCP server and not the primary address.
https://github.com/vyos/vyos-1x/blob/5d068442cf7b1863724c83168176ce2940a023fe/src/conf_mode/dhcp_server.py#L237

@erkin One additional detail: there is an attempt at clean up on entering configuration mode (in UnionfsCstore::setupSession); nonetheless, there are clearly potential (and potentially serious) issues here. Cf. T3054 for the comment on setupSession; there has been no serious investigation of the issue yet.

It seems Arp monitor not supported in 802.3ad mode

I've tested with replacing deb source from http://archive.repo.saltstack.com to https://archive.repo.saltproject.io in vyos-build/data/defaults.json

It is redirected from

http://archive.repo.saltstack.com/apt/debian/8/amd64/2017.7

to

https://archive.repo.saltproject.io/apt/debian/8/amd64/2017.7

We haven't seen memory leaks in keepalived in a long time, so I assume it's resolved.

Providing an entire path of the file i.e. /opt/vyatta/etc/key-pair.template instead of "@sysconfdir@/key-pair.template", makes the command executable.
IPSec VPN in X509 mode needs ca cert file, also server/client cert has to be signed by the CA for identification.
So, maybe rewriting this script will be helpful.
Any suggestions are welcome.

The main issue seems to be a lack of execute permissions on the script vyatta-gen-x509-keypair

Link to repo there
https://github.com/vyos/vyos-build/blob/06dc2469cc4c42a579a44e985d8099fc399f9c7b/data/defaults.json#L12

@olofl Can you re-check it? Or can we close it?

As I understand it a part of zebra, not specified to any protocol.
Maybe I'm wrong and we don't need it.

Why move the protocol specific route map to a new CLI node? This makes no sense to me.

A similar problem, only for ipv4 https://phabricator.vyos.net/T1053
As we can see ipv6 address before normalization without prefix
DEBUG: 2001:db8::191 before normalize
https://github.com/vyos/vyatta-cfg-system/blob/165e56e88763c40f13e6ef77f5df1c888fdfb899/scripts/vyatta-address#L38

@c-po
I propose to add "set routing-options x.x.x.x"
And also migrate protocols xxx route-map

set protocols bgp 65001 route-map RMAP
set protocols bgp|ospf|isis route-map RMAP

Does not reproducing on eve-ng.

you have an idea how the VyOS CLI commands should look like?

It will be enough to add a quote here?

"\`"

https://github.com/vyos/vyatta-cfg/blob/fa2b172512aa024a9853166528c9e6601fde94d8/src/cli_new.c#L1886-L1888

@Dmitry I can't reproduce it anymore VyOS 1.2.7

vyos@r2-lts:~$ touch tttt.txt
vyos@r2-lts:~$ ls
1.txt  foo.txt  ntp.conf  ntp.conf.2021-05-13-1945.pre-migration  ntp.conf.2021-05-13-2107.pre-migration  test.py  test.txt  tttt.txt  [email protected]
vyos@r2-lts:~$ 
vyos@r2-lts:~$ reset vpn remote-access user 
Possible completions:
  <text>        Terminate specified user's current remote access VPN session(s)

Default value https://github.com/vyos/vyatta-conntrack-sync/blob/7a8827e0d72cf771b0551915d738abe4838c0915/templates-cfg/service/conntrack-sync/mcast-group/node.def#L2