Nice. Is this syntax supported in vyos or it needs some development?

It is possible but with specific syntax
I found some examples:

nft insert rule ip filter VYOS_FW_FORWARD ip 'saddr & 0.255.0.255 != 0.11.0.13' counter

OK. I was trying to migrate from an EdgeRouter and this is a rule I used to have.

@patrickli nftables is not engine for iptables. It is programs to work with netfilter
That's why I ask for the real example

root@r1:/home/vyos# nft insert rule ip6 filter INPUT ip6 saddr ::dead:beef/::ffff:ffff counter
Error: syntax error, unexpected string, expecting number
insert rule ip6 filter INPUT ip6 saddr ::dead:beef/::ffff:ffff counter
                                                   ^^^^^^^^^^^
root@r1:/home/vyos#

Yeah nftables is just the engine for iptables. EdgeOS supports this syntax.

@patrickli In 1.4 we don't use iptables, we use nftables
LInk to nftables example will be helpful.

@patrickli Could you attach an example of VyOS configuration with set service upnp xxx
If you manually change upnpd.conf does it work correctly?

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

Great, thanks

It seems after this commit https://github.com/vyos/vyos-1x/commit/08cb762347208b21a8cbf81f7b35707d7e6dd4ac
I’ll take a look later

Got the PR working:

Using the pull requests filesystem copy, same place, new error:

vyos@vyos-515:~$ cat /var/log/vyatta/*log
cp[/opt/vyatta/config/tmp/new_config_1615]->[/opt/vyatta/config/tmp/tmp_1615/work]
cp w->tw failed[unknown exception]
cp[/opt/vyatta/config/tmp/new_config_2665]->[/opt/vyatta/config/tmp/tmp_2665/work]
cp w->tw failed[unknown exception]
vyos@vyos-515:~$ dpkg -l|grep vyatta-cfg
ii  libvyatta-cfg-dev                    0.102.0+vyos2+current5              amd64        libvyatta-cfg development package
ii  libvyatta-cfg1                       0.102.0+vyos2+current5              amd64        vyatta-cfg back-end library
ii  libvyatta-cfg1-dbgsym                0.102.0+vyos2+current5              amd64        debug symbols for libvyatta-cfg1
ii  vyatta-cfg                           0.102.0+vyos2+current5              amd64        VyOS configuration system
ii  vyatta-cfg-dbgsym                    0.102.0+vyos2+current5              amd64        debug symbols for vyatta-cfg
ii  vyatta-cfg-qos                       0.15.42+vyos2+current1              all          VyOS Qos configuration templates/scripts
ii  vyatta-cfg-system                    0.20.44+vyos2+current22             amd64        VyOS system-level configuration
vyos@vyos-515:~$ uname -r
5.15.59-amd64-vyos-sv
vyos@vyos-515:~$

If Linux maintainers backport the delta causing this to 5.10, it could become a rather pressing concern, but for now merely a show-stopper in terms of moving past 5.10LTS.

Created a pull request implementing a rudimentary fall-through-on-exception to standard API from the Boost version @ https://github.com/vyos/vyatta-cfg/pull/49
Have not built it yet, nor am i a formal C++ developer (hackers are informal everything developers and rarely formal anything developers), so would appreciate eyes on and sanity checks.
Exception can probably be scoped better to only trip on EXEDEV but i dont see a logical problem with falling-through like this on other errors (is this a bad assumption?).

PR https://github.com/vyos/vyos-1x/pull/1466
Let me know if there is what you are expecting,
requires more tests

set nat static rule 10 destination address '10.0.1.1'
set nat static rule 10 inbound-interface 'eth0'
set nat static rule 10 translation address '192.168.1.1'

@artooro Did you try listen-port option for this case?

set service https api gql
set service https api keys id KID key 'foo'
set service https api socket
set service https virtual-host foo listen-port '2580'

Check:

vyos@r14# sudo netstat -tulpn | grep nginx
tcp        0      0 0.0.0.0:2580            0.0.0.0:*               LISTEN      3570/nginx: master  
tcp6       0      0 :::2580                 :::*                    LISTEN      3570/nginx: master  
[edit]
vyos@r14#

@n.fort Create please PR for 1.3

@aserkin Will be present in the next rolling release.

@ajgnet Could you show routes after this bug?

sudo ip -6 route show
sudo ip -6 route get 2607:f8b0:4006:80d::200e

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

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

I've verified this behavior with 1.4-rolling-202207290217 and 1.4-rolling-202204250217.

PR https://github.com/vyos/vyos-1x/pull/1463
PR https://github.com/vyos/vyatta-cfg-system/pull/184

Hi Viacheslav
Sorry, i probably misspelled the config option. Actually it's availabe at [radius] section of accel-ppp.conf.
Below is the [radius] section from my /run/accel-pppd/l2tp.conf after i changed
/usr/libexec/vyos/conf_mode/vpn_l2tp.py:

What version you are using?

Allow me to proof the opposite.

As remarked and as expected, this option is not enable by default.
Proofs:

• Fist scenario: no ping-check option introduced in configuration:

In T2518#127884, @jack9603301 wrote:

@ajgnet If you have a way to limit the dynamic prefix to a known prefix, then using 1:1 NAT66 prefix translation should work (only the host segment is dynamic)

Yes, would be great to fully support dynamic prefix when the prefix is not known

Will be fixed in https://github.com/vyos/vyos-1x/pull/1458

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

ping-check shouldn't be allowed by default
To enable it you have to set set service dhcp-server shared-network-name Lan01 ping-check
There is no configuration in generated .conf:

vyos@r14# cat /run/dhcp-server/dhcpd.conf | grep ping
[edit]
vyos@r14#

I have tested macsec with gcm-aes-256. It works. (1.4-rolling-202208080217)

I have tested on 1.4-rolling-202208080217.
The first problem was fixed.
The second problem is not fixed

Hello, This functionality for nat66 is described here:
https://phabricator.vyos.net/T4586

hi, you can set this to a subtask of my task

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