As the title says, after upgrading to 24.10.0 my firewall traffic rules stopped working.
For example, I have this rule to block cloud gaming:
config rule
list proto 'udp'
option src 'wan'
option dest 'lan'
option target 'REJECT'
option dest_port '49003-49006'
option name 'Block-GFN-XXXX'
option enabled '1'
list dest_ip '192.168.X.XXX'
option family 'ipv4'
It worked fine on 23.05.5.
I even downgraded back to verify this and yes it works again after downgrading.
I haven't seen any changes related to the firewall in the release notes, so the configuration from 23.05.5 should be working properly with no changes.
I haven't verified the other traffic rules, but if none of them are working, it's a serious security issue. So, in the meantime, I'm downgrading back to 23.05.5.
Device: Xiaomi Mi Router 4A Gigabit Edition Platform: ramips/mt7621
This rule should be unnecessary in most configurations since unsolicited wan connections are not allowed. So with or without this rule, I'd expect that this traffic would not have an ingress path.
Let's see the full firewall config file to better understand what is happening.
P.S. You don't need to redact RFC1918 addresses (such as 192.168.x.x, 10.x.x.x, 172.16.x.x - 172.31.x.x) -- they are not sensitive information.
This rule does have an effect and I've been using it for a few years now (and even on older OpenWrt versions since 21 or something).
Even though the client connects to the cloud server, not vice versa, the traffic is returning from the cloud to the client via the same connection.
Unfortunately, I already downgraded to 23.05.5 as I was concerned with traffic rules not working. So I can't provide any relevant logs at the moment, but I'm sure this behavior can be reproduced with other similar rules on 24.10.0.
Maybe I can try it one more time to save logs later as I don't want to disrupt my home network now.
Are you using the same config files for 23.05 as you were trying to use for 24.10? If so, let's see the configs so we can understand two things:
Why the rule is having an effect in 23.05 (as I mentioned, it shouldn't with a default type config, but I'm guessing there are deviations from the default such that the rule has a purpose and effect).
Why the rule might not be working in 24.10.
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/firewall
You don't have any port forwards that would allow this traffic to ingress unsolicited, so I'm guessing that these are the return paths for traffic that is initiated on by the game. Is your intent to block these ports such that the games don't work? That would be the only reason to block those ports.
Your rule covers inbound audio and video, and part of the inbound remote input (there's also a TCP component).
You may need to add TCP for 49006 -- either in a separate rule or by removing the UDP proto (by default, if nothing is specified, it is UDP + TCP).
You might try removing the destination IP and the destination zone from the rule. This will cause the ports to be blocked for all hosts on your lan (and if that's specifically not desired, it will at least be a good test to see if the rule works when the destinations are not specified).
The reason I think this is needed is because the incoming packets are not destined for 192.168.2.165 -- they're actually destined for your router's address, and then the router will route them to the system that is running the game.
The other issue might be that the game opens a port on its local host, but the port that's actually opened on the router for established/related return traffic may or may not actually be these ports... so the traffic might not be coming into these ports from the internet to the router, but rather from the router (post NAT) to the game.
Yes, the rule is intended to block cloud gaming (return traffic) for a specific device only. It is enough to block a new session or terminate an existing one. I've been using it for many years even with older firmware versions. It's always been working like a charm until 24.10.0, which I don't see a reason not to work.
I don't know the deep details of a technical implementation on the cloud provider's side but I think it's irrelevant as it works on any other version up to 23.05.5.
So regardless of how this is implemented, it must be something different in the firmware itself related to the firewall.
As I don't see any firewall changes in the release notes, I think that could be a bug.
root@MIR4A-Travel:~# nft list chain inet fw4 forward
table inet fw4 {
chain forward {
type filter hook forward priority filter; policy drop;
iifname "br-lan" jump forward_lan comment "!fw4: Handle lan IPv4/IPv6 forward traffic"
iifname "pppoe-wan" jump forward_wan comment "!fw4: Handle wan IPv4/IPv6 forward traffic"
ct state established,related accept comment "!fw4: Allow forwarded established and related flows"
jump handle_reject
}
}
I can post the entire ruleset but this is the chain that matters in the context of the issue.
Unfortunately, I can't get similar output from 24.10.0 now as I downgraded back already and don't want to disrupt my home network with router reboots. I'll post it also if I get a chance to play around with my router.
That is by @vgaetera , nothing to do with standard firewall.
EDIT: you are welcome to re-arrange forward chain in /usr/share/firewall4/templates/ruleset.uc (backup is under /rom if fw4 check barfs out)
Sorry, I didn't get your recommendation.
What do you mean by standard firewall?
And why do I need to manually re-arrange fw4 templates, which I never did before?
My current configuration works fine (unless I upgrade to 24.10.0), could you please explain what exactly seems wrong to you in it?
chain forward {
type filter hook forward priority filter; policy drop;
ct state established,related accept comment "!fw4: Allow forwarded established and related flows"
iifname "br-lan" jump forward_lan comment "!fw4: Handle lan IPv4/IPv6 forward traffic"
iifname "eth0.2" jump forward_wan comment "!fw4: Handle wan IPv4/IPv6 forward traffic"
iifname "br-iot" jump forward_iot comment "!fw4: Handle iot IPv4/IPv6 forward traffic"
jump upnp_forward comment "Hook into miniupnpd forwarding chain"
jump handle_reject
}
So it looks like you (or someone else) has altered your firewall, those changes do not carry over automatically if you upgrade
Hint: the script to alter the firewall rules needs an update
You used some guide to patch fw4 template files, I perfectly remember changing precisely those lines.
You can get future firewall.uc version here (moving drop invalid earlier in ruleset away from forward chain):
Click "view file" on top right, then download raw file and save into /usr....templates/ and the vgaetera's patch will work again. Or you do the modification yourself with e.g. notepad++
I tagged your patch author, wait a week if they want to assist. OK?
Assuming it is actually new, there should be no matching conntrack records.
If the source is in the Internet, the destination should match the WAN IP of your router.
Unless you have a matching DNAT rule, it will retain the destination IP.
It will not be routed, will not reach the forward chain, and will be filtered in the input chain.
Meanwhile, the rule in the OP only applies to the forward chain, not the input chain.
