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

From ISC-DHCP manual pages:
https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcp-options

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

In fact you find a new bug in 1.4

Seems to be working fine as far as I can see.

Hello @Viacheslav, thanks for reply, so, if you'll bridge vtun94 and eth0.94 to br94 will it work in L2 level?
Did you push this update to nightbuild?

Some details in T4193

Resolved in T3873

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

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

Okay, thanks for the update. I have found a conntrack issue in the code. Will have a fix in shortly.

Looks like I see the same issue for 1.3.0. Reproducing steps:

set interfaces ethernet eth1 address 'dhcp'
set protocols static table 1 route 0.0.0.0/0 dhcp-interface eth1

Thanks, this does fix the ICMP issue, however rule 10 which is supposed to accept packets with related/established states (say a HTTP response following a request), doesn't seem to match any packets, and the packets get dropped by the default rule.

TCP Flags seems to be working on firewall filter config.

Tested on VyOS 1.4-rolling-202201180317 and working as expected

Fixed in 1.4 PR: https://github.com/vyos/vyos-1x/pull/1176

The XDP proof of concept program that is availbale in 1.4 does not support 802.1q - those headers are not parsed and processed.

What would be the use-case? We can start PDNS in one VRF context only.

You need to remove the state new match on the rule and it'll work.

Tested and working as expected on VyOS 1.4-rolling-202201150317

There are some issues with powerdns in vrf context.

Included those flags in PR: https://github.com/vyos/vyos-1x/pull/1174

Think 2 flag options should be added.
According to nft wiki these are all the flags that nft could match: tcp flags { fin, syn, rst, psh, ack, urg, ecn, cwr}

Included in PR: https://github.com/vyos/vyos-1x/pull/1174

It is a different task, it extends only the range which you can to use for rule numbers.
For example, if you want 3 rules
Rule 100, rule 1000, rule 10000 etc.
Accepting time it is another task. B.t.w firewall was rewritten in 1.4, I hope that commit time was decreased.

I think we will have a problem with such a large number of rules. Now, if there are 1500 vyos rules, it takes 30 minutes to load. If there are 999999 rules, it will take a very long time to load.

Thanks, will include a fix in a PR shortly

I can see the fix, but now trying invert selection on tcp flags doesn't work

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

Testing this feature in VyOS 1.4-rolling-202201100317 I'm getting some unexpected behavior.
Config:

For full support we need this added to FRR: https://github.com/FRRouting/frr/pull/9204

PR for 1.3 https://github.com/vyos/vyos-1x/pull/1172

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

PR for 1.3 https://github.com/vyos/vyos-1x/pull/1170

PR for 1.3 https://github.com/vyos/vyos-1x/pull/1170

Re-tested in VyOS 1.4-rolling-202201140317
Now it works, thank you!

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

@NikolayP Could you re-test it?

Some detail here T1280

@sdev: in your original commit for this task, recent rules are somehow semi-discarded (the time/counter condition will not be written out; however, the action will be written out) because of an apparent problem with nftables in this area.

Thanks; I just tested commenting out line 5 of that file, and it successfully works around the issue, allowing me to set a link-local IPv6 address as my endpoint. The wireguard connection itself also works, and I can pass traffic.

@odhnera Try to comment or delete the validation string and restart vyos-configd service

Getting link-local addresses to work would probably be very low-priority, but I did run into an extremely niche case where I wanted to do that. It's not the type of situation that would happen in a production environment, but I was running VyOS on a computer tethered via ethernet to an Android-based phone, and I wanted to connect to a wireguard peer running on the phone. Modern version of Android randomize the IPv4 address of their tethered interface on each reboot, but their link-local IPv6 address remains the same, making it more convenient to use it.