OpenWRT 24.10 forward Security Issue

Hello,

I have a couple of Asus AX4200 with OpenWRT 24.10 ( own build, It is more or less equivalent to the current official release)

The point i'd like to highlight is the nft tables rules created to deal with the forwarding traffic, to me they seem to be wrong.

Let me explain why, the very first rule send all tcp and udp flows through the flow tables, ( Wich is basically an accept all, and after that there are the rules to check the flows against the connection state.

This to me is clearly wrong, the logic to use the flow tables shall use the state.

M41n_AX4200:~# nft list chain inet fw4 forward
table inet fw4 {
chain forward {
type filter hook forward priority filter; policy drop;

Here the first rule allows every single tcp and udp flow go through flow tables without perform any single logic regarding connection tracking state

            meta l4proto { tcp, udp } flow add @ft
          ###here it takes into account the connection tracking state... But the packets already had been allowed 

ct state vmap { invalid : drop, established : accept, related : accept } comment "!fw4: Handle forwarded flows"

I would expect at this stage ( forward) something like that:

Ct state { established, related } meta l4proto { tcp, udp } flow add @ft
Ct state invalid drop

other rules

What do you think?
The other option could be perform this logic at pre- routing hook, but clearly this is not the case.

To wrap up , currently with the hardware acceleration, fw4 does not block any forward traffic

(Probably, if the flow doesn't go through any rule or default zone police before which accept this issue might not be a problem, but i believe it will be good change this logic to another one which ensures that only already accepted or valid flows go through the flow tables or hardware acceleration in those devices which support it.

You spotted it too....
Download ruleset.uc from MY pr

It also makes drop invalid before nat helpers.

flow offload does not explicitly ALLOW any packet. It just tries to add it unsuccessfuly at enormous cpu cost to a flow table.

1 Like

No idea how it could perform anything in prerouting hook when it works only in filter+forward .
it also restores offload on icmp (eg frag-needed) related, so the tcpudp filter is 1mm off the builtin ct protocol tcpudp

Yes... Regarding the pre routing... Just forget it.
I was thinking at loud.
I will try your solution, thanks!!

Yeah bro, if you find anything else fishy feel free to share.
I am testing on this router exactly. Check fw4 pr-s, most of them remove unneded processing from no-offload chains.