ruleset: also run through the custom includes for the loopback interface

[feckert]

Before this change, the user defined include rules in the output and input chain were not evaluated for the loopback interface. Traffic related to this interface was always accepted.

To ensure that the custom rules also apply to the loopback interface, move the custom rule in front of the input and output chain. These changes make it possible to evaluate rules for the loopack interface as well.

I also posted this on the mailing list a year ago. But then it didn't go any further. So now I'm trying it via github.

[brada4]

Is it same? (gotta rebase that one anyway) https://github.com/openwrt/firewall4/pull/22

[feckert]

@brada4 I would say no. My point is that packets coming or going to the loopback interface should also run through the custom chain-prepend rules. Which is not the case so far. I have a service that is bind to the loopback interface and the traffic for this service should also go through the custom fw4 rules.

If I understand yours correctly, then this is about offloading?

[brada4]

No the part of swapping rules

iif lo accept
state established accept or offload

into

place A (you can reach it with /etc/nftables.d/)
state established accept or offload
place B (more efficient)
iif lo accept

I dont want to break your idea, just understand the intentm

[brada4]

Which one?

        #
        # Filter rules
        #

        chain input {
                type filter hook input priority filter; policy {{ fw4.input_policy(true) }};

A {% fw4.includes('chain-prepend', 'input') %}
                ct state vmap { established : accept, related : accept{% if (fw4.default_option("drop_invalid")): %}, invalid : drop{% endif %} } comment "!fw4: Handle inbound flows"
B {% fw4.includes('chain-prepend', 'input') %}
                iif "lo" accept comment "!fw4: Accept traffic from loopback"

[brada4]

Like this? Ill patch up tests if it looks right to you. https://github.com/brada4/firewall4/commit/0e76fb41e6dc4fbeab71ae15426b03603aee3b70

[feckert]

@brada4 I can't say anything about that yet. I haven't had a closer look at your change. I can only say that with my PR I want that packages from the loopback interface should also hit the chain-prepend rules.

[brada4]

Before

loop
custom
state

Yours

custom
loop
state

Mine

custom 
state
loop

Ie i remove 2 meta integer compares from normal in/out connections making them 1Mbps faster on low end devices.

[feckert]

Before

loop
custom
state

Yours

custom
loop
state

Mine

custom 
state
loop

Ie i remove 2 meta integer compares from normal in/out connections making them 1Mbps faster on low end devices.

@brada4 The point is that the costum rules must also apply to the loopback device. If this is the case with your solution then I am happy.

If I look at your commits in #22 then you should use a prefix your commit header (have a look to the other commits in this repository). Also describe exactly what you are doing. Maybe then the review will be easier for the maintainer?

Can I support you in any way to get #22 merged?

[brada4]

I am splitting up #22, it is about distinct new features but in same script lines. So next one : 3 places of drop invalid become 2 3rd depends on 2nd - guard offload by ct state established (cf firewalld vs vyos) 2 after 3 adds dozen lines of code in between kinda k.i.s,s.

For the order - yes custom rule will precede iif lo

[feckert]

@brada4 Unfortunately, nothing is progressing here and in this PR. Is there anything I can do to help?

[brada4]

If you point @jow- to either of PRs you need there is slim hope he speed runs through all

[reinerotto]

@brada4 Unfortunately, nothing is progressing here and in this PR. Is there anything I can do to help?

I strongly support this patch request (PR ?). It is required to properly install any tproxy-dependent package, to work for local traffic, too.

[brada4]

@reinerotto please compare to https://github.com/openwrt/firewall4/pull/56 - whether ct state established accept ; tproxy (56) tproxy ; ct state established (this 55) is needed.

Documentation examples do not have anything in regard https://netfilter.org/projects/nftables/manpage.html In other news it is appended after all rules.... https://wiki.squid-cache.org/Features/Tproxy4#iptables-on-a-router-device

That makes me think order is indifferent....

[reinerotto]

That makes me think order is indifferent....<< No. Your example regarding squid works for CLIENTS only, I strongly suspect. Not for local traffic. Needs special trick, then (for LOCAL traffic to be t-proxied, i.g. dnsmasq. Here for hev-socks5-tproxy, but should work for squid, as well) ( https://github.com/heiher/hev-socks5-tproxy):

Thus, based on hev-socks5-tproxy docs, I created /etc/setup/hev-socks5-tproxy-fw2.nft: #Only for local mode #chain output_tproxy meta mark 0x438 return ip daddr @byp4 return meta l4proto { tcp, udp } counter meta mark set 0x440 #}

And then I use it like this: ....#excerpt from /etc/config/firewall: config include option type 'nftables' option path '/etc/setup/hev-socks5-tproxy-fw2.nft' option position 'chain-post' option chain 'mangle_output' ... to make shure, hev-socks5-tproxy-fw2.nft is executed BEFORE chain output (prio: filter) will simply accept this local packet. However, this is only a workaround for not being able to include IN VERY BEGINNING of output chain; it would be much clearer, to rectify this.

Am Montag, 13. Oktober 2025 um 13:14:10 OESZ hat Andrew @.***> Folgendes geschrieben:

brada4 left a comment (openwrt/firewall4#55)

@reinerotto please compare to #56 - whether ct state established accept ; tproxy (56) tproxy ; ct state established (this 55) is needed.

Documentation examples do not have anything in regard https://netfilter.org/projects/nftables/manpage.html In other news it is appended after all rules.... https://wiki.squid-cache.org/Features/Tproxy4#iptables-on-a-router-device

That makes me think order is indifferent....

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[brada4]

ip daddr byp4return

Absolutely contradicts table purpose - why would you blindly pass bogon addresses before any other rule (it bypasses rest of rules)

IMO make it eg

    chain hev-output {
        type route hook output priority mangle - 1; policy accept;
        meta mark 0x438 return
        ip daddr @byp4 return
        ip6 daddr @byp6 return
...

[brada4]

https://github.com/heiher/hev-socks5-tproxy/blob/main/README.md#netfilter make it priority whatever -1 to run complete chain before or +1 to run after. it is not meant to be merged with real rule chain....