Yes, boot\x86\wdsnbp.com is a proper filename, and this further correctly translates to double backslash in the dhcp.conf file at /run/dhcp-server/dhcpd.conf, as I noted. Why it is so, explained for example here: https://www.linkedin.com/pulse/quit-thinking-look-matthew-topper
And with such a setting network boot works just fine.
The problem is that after each reboot the vyos configuration scripts, I guess, double the number of backslashes in the config, that further leads to doubling them in the dhcp.conf. And on, and on. This actually breaks the network boot, and manual intervention is required after each router reboot.

In T5814#171114, @Apachez wrote:

On the other hand I would expect someone aka the admin who will configure an enterprise firewall such as VyOS could be called to have at least SOME basic knowledge and also some interest to read the documentation on how to configure the firewall.

As a side comment, the new firewall system allows more granular control and sometimes may simplify configuration. It follows better the lower level logic of nftables.

Yes, I agree with that, readability will be better if everything is in order.

@n.fort
Looks like 1) and 2) is correct, as well as 'Action=accept in vyos command shall remain as accept in nftables'.
However, the 3) is not obvious to me. As long as all rules with Action=Accept in both IN and OUT chains will migrate to Action=return, looks like there should be no difference in order, other than probably for performance reason.

@zsdc I built the image now, and it works as expected. The issue looks resolved. Thank you.

Yes, T4737 looks the same.

In T5243#149267, @Viacheslav wrote:

Maybe the related bug described in T4737
Could you show a version of FRR?

show version all | match frr

I just built ISO from the 1.3 branch and tried (1.3-rolling-202202171824). ocserv works normal. The issue is probably resolved.
Thank you.

@Viacheslav As I said: every rolling version of VyOS 1.3 branch starting from mid-January. I built ISO several times during this month. Last one I tried today (built today). All of them behave like this in my two different routers. Last time ocserv worked was middle of December build.

Same as T3919

I confirm. Same as T3934