Should be fixed in https://github.com/vyos/vyos-1x/pull/1241

Should be fixed by https://github.com/vyos/vyatta-cfg-firewall/pull/32

We confirmed the problem - some serial consoles continue to work well, some are not initialized properly with the --keep-baud option. For example, this can be reproduced in the SOS console in Equinix Metal.
Originally, the problem comes from a systemd service template.
Since it is not completely clear if the option is necessary in one case or another, it seems that the best solution would be to provide the ability to set/remove it from the CLI, so everyone may configure what works best for his hardware.

Suggested fix: https://github.com/vyos/vyatta-op/pull/52

PR to fix the problem: https://github.com/vyos/vyos-1x/pull/1128
It is compatible with both 1.3 and 1.4, so can be cherry-picked from sagitta to equuleus.

Hardcoded version of the fix for 1.4:
https://github.com/vyos/vyos-1x/pull/1068
https://github.com/vyos/vyos-build/pull/201

The problem exists because of the IKEv1 limitation - peer ID is unknown at the authentication stage. Since, both DMVPN and L2TP are configured for any remote peer address, one of them intercepts customers of the other one during authentication because it is not possible to find out which service will be connected after Phase 1.

Technically, the other one is a duplicate, but there are more details already.

After the investigation, we figured out that it is possible to get the prefix and link-local address during the DHCP commit procedure.
The statement

log(info, binary-to-ascii(16, 8, ":", substring(option dhcp6.ia-pd, 24, 17)));

will give us the next info:

dhcpd[1568]: 40:20:1:ca:fe:11:11:ff:ff:0:0:0:0:0:0:0:0

So, a prefix can be extracted. Also, a link-local address may be generated from the MAC address extracted from the DHCP packet structure.

After some investigation, we figured out several ways how to solve or at least mitigate the problem. From my point of view, the optimal for both developers and customers is the next one.

The issue solved in the https://github.com/vyos/vyos-1x/pull/1017
However, the question if netplug script is necessary at all is still opened.

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

Thank you for testing! The change was backported to 1.3 and 1.2.

Hello, @nyamada!
Really appreciated for such a detailed problem analysis! The regex is fixed in the 1.4 version now.
Could you test it, so we can backport changes safely to 1.2 and 1.3?

They should be disabled by default, but there must be the ability to re-enable OIDs back from CLI.

PR: https://github.com/vyos/vyos-build/pull/179

It also works with the current VTI interfaces (sudo ip l set vti1 vrf VRF1).

@UnicronNL I would like to put default values in the config.boot file, and overwrite them from Cloud-init if a customer provides custom values.

The issue exists because the ifupdown package that is required for the eni renderer was removed by the https://github.com/vyos/vyatta-cfg-system/commit/3dd837f2d3518b7ddcf8e1ab68d8ab9f3eff0968
To not take back it again for all the platforms, the problem was resolved by the https://github.com/vyos/vyos-vm-images/commit/090e5367dc6df9b49c037e0b60f7adfafdf54a53 , so all the images created with the vyos-vm-images should not contain the problem with the renderer.

This task must be obsoleted by the https://phabricator.vyos.net/T2116

Just a small update on this.
PXE boot service for all 1.2 / 1.3 / 1.4 versions is up and running in private testing.

The root of the problem here is changed place for custom options and the ability to configure options that should be applied differently, depending on the place. In other words, "Additional OpenVPN options" becomes "Additional OpenVPN options. You must use the syntax of openvpn.conf in this text-field", but actually these variants are not fully equal and cannot be converted directly.

Still does not work in 1.4-rolling-202102060218

Moving tunnels between bridges works well in:
1.3-beta-202103110443
1.4-rolling-202102060218

Both UEFI and MBR boot modes are supported currently.
As a replacement for keys from Microsoft, it is possible to use our keys and ask users to install CA into a MOK database.

Most likely this should be done (after firewall rewrite) as jump statements.

Kernel related part is located here: https://github.com/vyos/vyos-build/tree/current/packages/linux-kernel
The rest is here: https://docs.vyos.io/en/latest/contributing/build-vyos.html

The idea stays actual, but unfortunately, it needs now to be rewritten according to the new config implementation.