[Feature Request] Prepend Firewall rule

[lleachii]

@Talkabout

I want to block traffic that goes to the internet, so I am assuming this is correct.

I don't think you understand what -o does...or should I say...what it won't do...

I need to know if these are real rules working now, so please be clear...especially since there are easier ways in the manual (and more secure) than this - to simply block kids...and because wan isn't a Linux PHY named on default OpenWrt for WAN...eth0.2 is the most common across devices with a built-in switch...and since your rule will only cover that PHY, and not the WAN zone (as I noted when explaining the exemption).

@Talkabout

No security considerations, as I am blocking additional traffic. Main purpose: "block children devices from the internet during sleep time"

Yes there are, I listed one:

@lleachii

Do you intend for this rule to stop the established,related connection that begun with an inbound or (e.g. 1st timer expired and ongoing) UDP too???

Given you mention parental controls again, I'll digress on the other inquires...can you simply explain why none of the parental control rules work for you (i.e. the ones that follow the instructions in the Wiki or in the forum)?

@Talkabout

being able to give it the highes priority (in my case executing it before RELATED,ESTABLISHED general rule)

I only read your reasoning is that you want it before any established,related rules - but I already described one problem that's likely an undesired security consequence of what your rule as-written - could do - contrary to your TRUE desires (i.e. it WON'T block the kid's device).

https://forum.openwrt.org/search?q=parental%20controls

• If your kid used a UDP-based VPN e.g. Tunsafe with Wireguard client...I think this rule wouldn't block it...
• nor most UDP-based A/V chats, video streams, etc...
• also if you made a VPN for the router, used Wireless WAN, etc. and forgot to edit that rule, the kids would still have Internet (because it didn't cover Zone WAN thru chains; but only the current interface for the ISP connection - this is the another security issue - making rules on the same layer of abstraction...exempting PHYs from a Zone)

...but I'll respectfully digress on that too so you can answer the relevant inquires about the priority, currently working rule and security implications (assuming you actually added/tested the rules as stated).

(I think teaching kids to be good netizens is better than this.)

[jow]

@Talkabout wants his parental control rules to be added before the generic established/related accept rule added by fw3.

Likely reason for this is the desire to cut established connections right away when the block rule time slot starts.

If the time rules are placed after the generic established/related accept rule, already established connections (movie streams, long running downloads, persistent VPN connections, ...) continue to function until they are either closed or timing out. This defeats the purpose of parental control rules somewhat where the expectation is that traffic forwarding is denied immediately once the block time frame is starting.

I can't think of a simple way to implement that in the current configuration model without changing a lot of the current firewall implementation.

[Talkabout]

I don't think you understand what -o does...or should I say...what it won't do...

I am terribly sorry, I copied the rule before correcting the outbound device, this is how it looks like in my current implementation, and works:
iptables -t filter -I FORWARD 1 -p tcp -m mac --mac-source XX:XX:XX:XX:XX:XX -o eth5 -m time --timestart 21:00:00 --timestop 07:00:00 --datestop 2038-01-19T03:14:07 --kerneltz -j REJECT
My router device has 6 network interfaces named eth0-eth5

Given you mention parental controls again, I'll digress on the other inquires...can you simply explain why none of the parental control rules work for you (i.e. the ones that follow the instructions in the Wiki or in the forum)?

The parental controls on the wiki work, but only for newly established connections, existing ones are not cut.

I only read your reasoning is that you want it before any established,related rules - but I already described one problem that's likely an undesired security consequence of what your rule as-written - could do - contrary to your TRUE desires (i.e. it WON'T block the kid's device).

Existing rule is working, blocking the devices as expected, even though they are using a security VPN to connect. This is why also UDP traffic needs to be blocked.

(I think teaching kids to be good netizens is better than this.)

I am not sure about how much experience with kids you have, but they are always trying to work around prohibitions. Today, in case of lots of devices flying around, it is hard to make sure kids are not using them at night, when they have to sleep. This is why I am trying to at least block any kind of internet activity. Additionally to that, of course, we are teaching our kids good behavior on the net, but that is a different topic altogether.

@jow Thank you very much for "understanding my requirement" and "explaining the difficulties in integrating it"!

[vgaetera]

A relatively simple way would be providing an option to change the position of the RELATED,ESTABLISHED rule like this:

• Prepend the main ruleset, i.e. the default behavior:

uci set firewall.@defaults[0].estab_order=0

• Prepend the default policy rule:

uci set firewall.@defaults[0].estab_order=1

[Grommish]

Another suggestion if your device has multiple Wifi radios is to put the kid devices on one radio and use scheduling to turn the radio on/off on your schedule.

You, and other devices you want to allow consistent access, go on the other radio (with it's separate key).

@Talkabout

I am not sure about how much experience with kids you have, but they are always trying to work around prohibitions. Today, in case of lots of devices flying around, it is hard to make sure kids are not using them at night, when they have to sleep

That would solve the issue unless they are using a wired connection, at which point, you've got bigger issues

[Talkabout]

@vgaetera yes, that would be a simple solution

@Grommish no wired connection so far. I also do not like the idea of spanning multiple SSIDs, but thanks for your suggestions

My current solution:

• Rule created via LUCI, including MAC Address and time definition
• Added speechful rule name to be able to match it in iptables command
• simple script to move the rule from the default zone to "forwarding_zone"

Here is the script, executed post firewall restart:

IFS=$'\n'
RULES=$(iptables-save -c -t filter | grep -i "children")

for RULE in $RULES
do
        RULE=$(echo $RULE | sed -e "s/^\[[0-9]*\:[0-9]*\]//g")
        DELETERULE=$(echo $RULE | sed "s/-A /-D /")
        NEWRULE=$(echo $RULE | sed "s/zone_user_forward/forwarding_rule/")
        eval "iptables $DELETERULE"
        eval "iptables $NEWRULE"
done

Until there is another solution on LUCI I will go with this one.

Thanks all!

[amteza]

Hi, @Talkabout,

This is exactly my approach. I mark my firewall rules description for future reordering with the chain I want it to go in:

And then I use a script to move then to the correct chain and reorder RELATED and ESTABLISHED ongoing connections:

# Rules to reorder
FWD_CHAIN="FORWARD"
CONN_REJECT="reject"
CONN_INVALID="INVALID"
CONN_ESTABLISHED="ESTABLISHED"

# Process any new rule from fw3 front-end that is tagged to $RULE_TABLE
RULE_ORIG="zone_lan_forward"
RULE_TABLE="forwarding_lan_rule"

# Mark to include as part of rule description in fw3 front-end
RULE_MARK="##$RULE_TABLE##"

# Reorder rules so REJECT rules come before ACCEPT conntrack rules
line_buffer=""
for ipt in ip ip6; do
    ${ipt}tables-save -c -t filter | while IFS= read -r line; do
        # If rule is a conntrack ESTABLISHED or INVALID rule, just add it to the buffer and do not output the line yet
        if [ -z "${line##*$FWD_CHAIN*$CONN_ESTABLISHED*}" ] || [ -z "${line##*$FWD_CHAIN*$CONN_INVALID*}" ]; then 
            line_buffer="$line_buffer$line\n"

        # Once we found the REJECT catch all rule print buffer right before    
        elif [ -z "${line##*$FWD_CHAIN*$CONN_REJECT*}" ]; then
            printf "%b" "$line_buffer"
            line_buffer=""
            printf "%s\n" "$line"
        
        # Add any marked rule in the rule origin to our user rule table
        elif [ -z "${line##*$RULE_MARK*}" ]; then
            printf "%s\n" "$line" | sed -e "s/$RULE_MARK//g;s/$RULE_ORIG/$RULE_TABLE/g"
        
        # Do not process, just print
        else
            printf "%s\n" "$line"
        fi        
    done | ${ipt}tables-restore -c -T filter
done

BTW, I found that if I enable Software offloading the ongoing connections are not killed, so because the RPi4 has more than enough power I have this option disabled.

This is my firewall.estab file and gets executed every time there is a change, and always after firewall.user, just in case:

config include 'estab'
	option path '/etc/firewall.estab'
	option reload '1'

Kind regards.