(Solved) 22.03 RC4 IPV6 traffic rule not working

Hi there,

Router: Xiaomi Redmi 2100
Firmware:22.03 RC4 self compiled
Network: op as main router, ISP modem bridged, native IPV6 with /64 prefix
Issue: I have a linux server in lan running aria2 for p2p bt download. When using 21.02 I configured the following for dynamic v6 firewall traffic rule and it worked well. "eui64" set on br-lan so openwrt do a static ip assignment based on clients' mac.

config rule
	option target 'ACCEPT'
	option src 'wan'
	option name 'aria2-ipv6-bt'
	option dest_port '51081-51082'
	list dest_ip '::abcd:a1ff:fe23:abcd/::ffff:ffff:ffff:ffff'
	option dest 'lan'

But when flashed to 22.03 I noticed this rule no longer works, as I can see no v6 peers connected when downloading in aria2.
I used online port scanner, and confirmed this. IPV4 redirect works, I can still download with my external v4 ip, but v6 ports are all closed/timed out even with the above rule.

I understand 22.03 switched to nftables and fw4 while 21.02 using iptables and fw3, so is this a bug? Should I expect it to be corrected in 22.03 stable? Or I should use different config in my firewall? Thx.

Anyone can lend me a hand here?

How does this affect the IPv6 address of the Linux server running aria2? Seems it should only affect the address of the br-lan interface on the router.

Are there any hits on the firewall rule? I suspect your destination address is not the right one, but I don’t know anything about aria2.

You can ignore the aria2 part, just treat the scenario as a server needs one port exposed on IPV6.
As for the eui64, I'm not an expert myself, but my understanding is that if I set this on lan interface, all clients will be assigned an IPV6 address based on the device's mac instead generating randomly, or you mean this only affects the lan interface itself, not its clients?


Anyway, running ifconfig on the Linux server shows the following, the "ff:fe" part of the v6 address it obtained indicates it uses eui64 option
x96

The intention is to have static v6 address for the later /64 segment so I can have a traffic rule in firewall to deal with dynamic v6 address change due to ISP address renewal.

Yes. I think the Linux server’s kernel will default to using eui64, so it’s just a coincidence that it matches how you set the br-lan interface.

Are both of those 2408: addresses the same on the eth0 interface? And what about checking the rule counter?

nft list ruleset | grep aria2

two v6 addresses on eth0 are different because op router rebooted while the Linux server did not. You think this is the culprit? Should I remove one?
nft list ruleset | grep aria2 result:

                ip6 daddr & ::ffff:ffff:ffff:ffff == ::abcd:a1ff:fe23:abcd tcp dport 18000 counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: aria2-ipv6-1"
                ip6 daddr & ::ffff:ffff:ffff:ffff == ::abcd:a1ff:fe23:abcd tcp dport 8686 counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: aria2-ipv6-2"
                ip6 daddr & ::ffff:ffff:ffff:ffff == ::abcd:a1ff:fe23:abcd tcp dport 51081-51082 counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: aria2-ipv6-bt"
                ip6 daddr & ::ffff:ffff:ffff:ffff == ::abcd:a1ff:fe23:abcd udp dport 51081-51082 counter packets 0 bytes 0 jump accept_to_lan comment "!fw4: aria2-ipv6-bt"
                ip saddr 192.168.66.0/24 ip daddr { 12.34.56.78, 192.168.10.10 } tcp dport 51081-51082 dnat ip to 192.168.66.66:51081-51082 comment "!fw4: aria2-bt (reflection)"
                ip saddr 192.168.66.0/24 ip daddr { 12.34.56.78, 192.168.10.10 } udp dport 51081-51082 dnat ip to 192.168.66.66:51081-51082 comment "!fw4: aria2-bt (reflection)"
                ip saddr 192.168.66.0/24 ip daddr { 12.34.56.78, 192.168.10.10 } tcp dport 18000 dnat ip to 192.168.66.66:18000 comment "!fw4: aria2-web1 (reflection)"
                ip saddr 192.168.66.0/24 ip daddr { 12.34.56.78, 192.168.10.10 } tcp dport 8686 dnat ip to 192.168.66.66:8686 comment "!fw4: aria2-web2 (reflection)"
                ip saddr 192.168.66.0/24 ip daddr 192.168.66.66 tcp dport 51081-51082 snat ip to 192.168.66.218 comment "!fw4: aria2-bt (reflection)"
                ip saddr 192.168.66.0/24 ip daddr 192.168.66.66 udp dport 51081-51082 snat ip to 192.168.66.218 comment "!fw4: aria2-bt (reflection)"
                ip saddr 192.168.66.0/24 ip daddr 192.168.66.66 tcp dport 18000 snat ip to 192.168.66.218 comment "!fw4: aria2-web1 (reflection)"
                ip saddr 192.168.66.0/24 ip daddr 192.168.66.66 tcp dport 8686 snat ip to 192.168.66.218 comment "!fw4: aria2-web2 (reflection)"
                meta nfproto ipv4 tcp dport 51081-51082 counter packets 2 bytes 100 dnat ip to 192.168.66.66:51081-51082 comment "!fw4: aria2-bt"
                meta nfproto ipv4 udp dport 51081-51082 counter packets 73159 bytes 9508448 dnat ip to 192.168.66.66:51081-51082 comment "!fw4: aria2-bt"
                meta nfproto ipv4 tcp dport 18000 counter packets 4 bytes 160 dnat ip to 192.168.66.66:18000 comment "!fw4: aria2-web1"
                meta nfproto ipv4 tcp dport 8686 counter packets 6 bytes 260 dnat ip to 192.168.66.66:8686 comment "!fw4: aria2-web2"

real ip filtered out.

Consider this solved on 22.03 RC5.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.