Time restrictions issue

yes if you add the directory to /etc/sysupgrade.conf

echo "/root" >> /etc/sysupgrade.conf

or add files to /etc/sysupgrade.conf

echo "/root/disable_firewall_rule_0" >> /etc/sysupgrade.conf
echo "/root/enable_firewall_rule_0" >> /etc/sysupgrade.conf
echo "#min hour day month day-week command" >> /etc/crontabs/root
echo "#0-59 0-23 1-31 1-12 0-6(0=Sunday) exec" >> /etc/crontabs/root
echo "0 7 * * * /root/enable_firewall_rule_0" >> /etc/crontabs/root
echo "0 23 * * * /root/disable_firewall_rule_0" >> /etc/crontabs/root

minutes, hours, day of the month, month, day of the week, command to execute
examples:

Exactly

see this links for any examples:

https://crontab.guru/#0_23_*_*_*

https://crontab.guru/#0_7_*_*_*

So I was able to confirm today that I believe it was after changing this

config redirect
        option dest 'lan'
        option target 'DNAT'
        option name 'Wireguard'
        option src 'wan'
        option src_dport '51820'
        option dest_ip '192.168.10.1'
        option dest_port '51820'

to this

config rule 'Wireguard'
        option target 'ACCEPT'
        option name 'Wireguard'
        option src 'wan'
        option proto 'udp'
        option dest_port '51820'

that a couple things are now broken. The first thing is that I have a Samba share on the router that will no longer map on the VPN client machines & the second thing is that it will no longer make the remote desktop connections to client machines in the field via NoMachine from the PC's on the local lan with the router.

This should not have impacted the things you're talking about.

I would imagine that it was the masquerading on the wireguard zone and/or the lan > wireguard forwarding.

I didn't know that you had other services like this running. While I probably should have asked, it also would have been useful if you had stated these facts.

Can you be more specific about the Samba connections. For example, what is the IP address of the samba client machines (or more specifically, are they on the router's lan or remotely connected via wireguard)? And what address is used to connect to the samba server on the router (the router holds a few addresses -- which one is used for the mapping)

This is actually likely a combination of factors, but not explicitly a problem with the router's config.

Specifically, Windows by default will block connection requests from hosts on a different subnet. When masquerading was enabled on the wireguard zone, the requests probably appeared to originate from the router itself (which would mean it looks like the local subnet from the perspective of Windows). With masquerading disabled, the Windows firewall is blocking these requests. Therefore, you can either re-enable masquerading or you can adjust the windows firewall to allow these connections.

The Samba / NFS clients connect offsite via Wireguard with 192.168.10.X.
NoMachine viewer on the local lan needs to access these client machines that are offsite via their Wireguard IP address & a specific port.

So I should revert this

config zone
            option name 'Wireguard'
            option input 'ACCEPT'
            option output 'ACCEPT'
            option forward 'ACCEPT'
            list network 'WireGuard'

back to this?

config zone
            option name 'Wireguard'
            option input 'ACCEPT'
            option output 'ACCEPT'
            option forward 'ACCEPT'
            option masq '1'
            option mtu_fix '1'
            list network 'WireGuard'

Sure, you can try that. It may resolve the problem, although it's more of a workaround than a fix. But yes, give it a shot.

You might also need to add this:

config forwarding
        option src 'lan'
        option dest 'Wireguard'

This was in the file previously, but didn't seem to make sense based on the information available at the time. I still am not sure that it's needed, but your remote access method might actually require this. On the other hand, I wouldn't expect this to work in conjunction with masquerading on the wireguard firewall zone.

So right now I'm offsite from the local lan & using Wireguard to tunnel into the local lan. I noticed that I was able to take control of another machine offsite via NoMachine as well as the machines on the local lan but for example if I were controlling one of the machines on the local lan I was unable to take control of an offsite machine until I readded your last suggestion so that is all good & working again but I still cannot MAP the Samba share from my location over Wireguard.

I have probably created this Samba link on the desktop of about 8 of his 20 PCs so far so that users can drop stuff to it. I'm trying to map it on my Win VM that I use to manage his stuff in order to ensure that it is still functioning on the other machines but keep receiving an error. I don't know if it is due to config changes we did or if Micro$oft networking is just being garbage.

Have you checked that the samba server is still running and that the drive (on /mnt/) is still mapped properly?

Yeah all of that is fine. I think it just comes down to Micro$oft networking being garbage because if I put the server address in an explorer window it shows up but still refuses to create a permanent mount. As usual thanks for all your help psherman! Now I'm just waiting until midnight to see if ncompact's suggestions have worked out for me.

So today my buddy made things a bit more complicated and wanted to setup the restrictions on 2 different kids separately. I believe you explained this well enough to where I was able to figure it out but I was watching the config page at midnight to see if the "allow" rules got disabled and it looks like they did not. The following is the commands I used.

cat << "EOF" > /root/disable_bryiar_internet
#!/bin/sh
#disable_firewall_rule_0
uci set firewall.@rule[0].disabled='1'
/etc/init.d/firewall restart
EOF

cat << "EOF" > /root/enable_bryiar_internet
#!/bin/sh
#enable_firewall_rule_0
uci set firewall.@rule[0].disabled='0'
/etc/init.d/firewall restart
EOF

cat << "EOF" > /root/disable_dj_internet
#!/bin/sh
#disable_firewall_rule_1
uci set firewall.@rule[1].disabled='1'
/etc/init.d/firewall restart
EOF

cat << "EOF" > /root/enable_dj_internet
#!/bin/sh
#enable_firewall_rule_1
uci set firewall.@rule[1].disabled='0'
/etc/init.d/firewall restart
EOF

chmod 700 /root/disable_bryiar_internet
chmod 700 /root/enable_bryiar_internet
chmod 700 /root/disable_dj_internet
chmod 700 /root/enable_dj_internet

echo "#min hour day month day-week command" >> /etc/crontabs/root
echo "#0-59 0-23 1-31 1-12 0-6(0=Sunday) exec" >> /etc/crontabs/root
echo "0 7 * * * /root/enable_bryiar_internet" >> /etc/crontabs/root
echo "0 0 * * * /root/disable_bryiar_internet" >> /etc/crontabs/root
echo "0 7 * * * /root/enable_dj_internet" >> /etc/crontabs/root
echo "0 0 * * * /root/disable_dj_internet" >> /etc/crontabs/root

& it appears that the top 2 rules were not disabled after midnight.

did you restart the "cron" service?

/etc/init.d/cron restart

so that the cronjobs are executed

ps: the "luci" interface will not be able to show if the rule is enabled/disabled but you can find out with the following command:

uci show firewall.@rule[0] | grep "disabled"
uci show firewall.@rule[1] | grep "disabled"

if the disable line appears whit "1"

Perhaps I miss this in the discussion, but assuming there are some allow rules- merely insert the time-based block rules before them.

From your screenshot, the block rules need to be moved up.

To be clear, the time rules should be in the block.

if the question is for me, this is what I recommended to the author of the post:

so that by disabling the rule(s) that allow the traffic (during the time when PCs will not need to surf the Internet), the one that the firewall will consider will be the next one that does not allow the traffic

the reason that led me to recommend this is that there might still be some related/established traffic that is allowed by the firewall structure

1 Like

There are some approach that could be done to limit kids internet time. Some of them are:

  1. Create a special SSID for kids. This SSID will turned on and off by script to rename it with different hidden SSID. By this way, they can't even see the SSID they can't use it when it's on internet off for kids mode
  2. Run static ipaddress for all kids gadget. By this way, beside blocking the mac we can also block the ip address for them (by firewall config). The phone should on mac phone, not a random mac address mode. If they are using ramdom mac then it's better to use no 1 approach
  3. You can also block their mac address on wireless section on specific time by put it on blacklist mac address and parents on whitelist mac.
  4. Cronjob for run automatically for all above approach

I rebooted the router after saving changes to ensure all services were restarted. So you are saying that luci will not show the reflected changes? I was unable to test beyond looking at what luci was showing because my buddy whose router this is went to bed early.

Can I make a suggestion... setup your own OpenWrt router at your home (even if not your main router) so that you can test all of the things locally.

This can be done with a relatively inexpensive new or used hardware so long as it is supported and has sufficient storage and RAM. If you have an old x86 machine or a Pi around, that can also be used, or even in a VM (although VMs may be a bit more challenging).

1 Like

My primary router here is also OpenWrt but I'm running 23.05.2 still because updating it breaks it & I haven't had time to set it all up again with a fresh install. I too am not running wireless on this box and have a commercial router piggybacking off of it for the few wireless connections that I need. The commercial router is running OpenWrt 21.02.3 because any further updates bricked it to where I had to reinstall.

yes if the following command is inserted in the called scripts:

uci commit

no if it is not inserted

show:
"Writes changes of the given configuration file, or if none is given, all configuration files, to the filesystem. All “uci set”, “uci add”, “uci rename” and “uci delete” commands are staged into a temporary location and written to flash at once with “uci commit”. This is not needed after editing configuration files with a text editor, but for scripts, GUIs and other programs working directly with UCI files. "

Let's unpack this a bit...

Ok... probably a topic for a different thread. But, you should seriously consider a second router to use as a test/dev device if you plan to support your friend's network with different requirements than your own.

What commercial router? Is this the one at your friend's house?