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

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

Here are a few examples and references online.

ip6tables man page: https://linux.die.net/man/8/ip6tables (search for ffff:ffff)
https://kajoh.de/ipv6-prefix-delegation-and-iptables.html
https://github.com/opnsense/core/issues/3247
https://forum.mikrotik.com/viewtopic.php?t=179161

@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# 

root@r1:/home/vyos# nft add rule ip filter FORWARD ip saddr 10.0.0.0/255.0.255.0 counter
Error: syntax error, unexpected string, expecting number
add rule ip filter FORWARD ip saddr 10.0.0.0/255.0.255.0 counter
                                             ^^^^^^^^^^^
root@r1:/home/vyos#

Iptables links don't work for nftables.

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

Quite surprising that nftables doesn't support this syntax, as iptables also works with netfilter isn't it?

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

nft insert rule ip6 filter VYOS_FW6_FORWARD ip6 'saddr & ffff:0:ffff:0:ffff:0:ffff:0 == feed:0:c0ff:0:c0be:0:5678:0 ' counter

list

table ip filter {
	chain VYOS_FW_FORWARD {
		type filter hook forward priority filter; policy accept;
		ip saddr & 0.255.0.255 != 0.11.0.13 counter packets 0 bytes 0
		jump VYOS_POST_FW
	}

}
table ip6 filter {
	chain VYOS_FW6_FORWARD {
		type filter hook forward priority filter; policy accept;
		ip6 saddr & ffff:0:ffff:0:ffff:0:ffff:0 == feed:0:c0ff:0:c0be:0:5678:0 counter packets 0 bytes 0
		jump VYOS_POST_FW6
	}
}

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

Not supported at the moment, but we can look into adding it for both ipv4/v6 in 1.4

I'd like to see this feature added so I went ahead and implemented it: https://github.com/Rain/vyos-1x/commit/975f4fc358f0073f1ad825ea209169766dc2fa51

There is still a little bit of work left to do but I'd like to discuss the scope of what we'd like to accomplish here before going any further.

nftables seems to support arbitrary netmasks (really just bitmasks) for ranges and sets as well. For example, the following would be valid rules:

ip6 saddr & ::ffff:ffff:ffff:ffff == ::beef:0000-::beef:ffff counter drop
ip6 daddr & ::ffff:ffff:ffff:ffff != @SOME_ADDRESS_GROUP counter drop

Is this something we'd like to support as well? Adding support for ranges would be a few simple additions to my existing changes, but supporting address groups will be a bit more involved and some decisions will need to be made (mainly where the mask is defined in the configuration).

Ubiquity's routing software supports firewall rules with arbitrary netmasks on addresses (@patrickli confirms this above). Does anyone know if they support arbitrary netmasks on address groups as well?

On second thought, maybe instead of supporting the ::beef/::ffff syntax we add an address-mask field to source and destination?

Something like:

set firewall ipv6-name WAN-IN6 rule 10 action accept
set firewall ipv6-name WAN-IN6 rule 10 source address ::dead:beef
set firewall ipv6-name WAN-IN6 rule 10 source address-mask ::ffff:ffff

set firewall ipv6-name WAN-IN6 rule 20 action accept
set firewall ipv6-name WAN-IN6 rule 20 destination group address-group WEBSERVERS
set firewall ipv6-name WAN-IN6 rule 20 destination address-mask ::00ff:ffff:ffff:ffff:ffff

That's the cleanest solution I can think of with the minimum amount of changes required.

A separate mask field is cleaner also from a documentation point of view. But how would you do it for an address/network group? It only makes sense for a single address I suppose.

I implemented address-mask as described above as well: https://github.com/Rain/vyos-1x/commit/ca6b7340714c6161337f508978b9834722be58dc

Personally, I think this is much better than the ::beef/::ffff syntax. That said, I'll wait until others weigh in before continuing and creating a pull request.

In T4612#135440, @patrickli wrote:

But how would you do it for an address/network group? It only makes sense for a single address I suppose.

Arbitrary netmasks certainty don't make sense for network groups. I'd argue that it makes enough sense with address groups and ranges to support it, though. Consider having a few web servers that all need port 80/443 allowed. Instead of creating a number of different single-address rules with masks, you could instead create one address group and one single rule.

Also, it can be wildcard-address
@Rain Could you create a PR?

I'm not sure if wildcard-address fits. The address and the mask together combine to create the wildcard.

I apologize for the delay, but I made a pull request for testing & review along with a pull request adding documentation:

PR: https://github.com/vyos/vyos-1x/pull/1641
Documentation PR: https://github.com/vyos/vyos-documentation/pull/885

I'm happy to make any adjustments necessary (or scrap the address-mask idea and finish up implementing the ::dead:beef/::ffff:ffff syntax instead).

Also, regardless of what route we decide to take, I'd suggest renaming this task to "Support arbitrary netmasks in firewall rules" (or similar) for future clarity in the changelog.

I've been testing this for a few weeks now at home and haven't noticed any issues. That said, while I have 6 network zones and a few public services running, my home network isn't very complicated and doesn't have any "exotic" firewall rules. Since the changes are fairly minor and the smoketests pass, I don't think there should be any issues, though.

If someone has a complicated lab setup with a ton of different types of firewall rules and can test this, that would be great! Since the pull request was merged, it is included in 1.4-rolling-202211250318.

If anyone runs into issues, please let me know!