Issue with Parental Control - Time Scheduling

[Josh Opa]

Time scheduling does not work anymore for some clients, however, it still works for others. It had been working fine for quite some time before that.
Those problematic clients connect via wifi (not sure this is a factor, their are Android phones so I cannot test them with a wired connection). As soon as time scheduling is enabled, their internet Connection is blocked, regardless of the time of the day. Even if the time management schedule is edited to allow every hours of every day, internet connectivity is still blocked. If the schedule is "disabled", the internet connection is restored as expected.


Setup:
- main router: RT-AC86U, now running on FW 384.18 but the problem appeared when running FW 384.17, maybe even on previous versions. JFFS not enabled (I ran diversion on it some months ago before but the router became unresponsive and I had to do a reset and reconfiguration)
- an RT-AC68U used as AiMesh node to extend wifi coverage, running same FW version as the RT-AC86U
- using the ASUS android app most of the time, rather than the web UI, to enable/disable as well as edit time scheduling

What I already tried:
- FW upgrade
- Router reboot. Turn on/off
- Disabling AI Mesh node and running only with RT-AC86U
- deleting time scheduling entries related to the problematic clients and recreating them
- testing with a schedule that allows all time slots


I guess my next step would be to do a factory reset of the router and reconfigure it completely. But I have some 40ish DHCP entries as well as a few openVPN configurations so I know it takes a while to do that...

Before I do that, I was wondering if someone would have an idea on how to debug this time scheduling issue further and try to find a reason for this unexpected behavior.

When searching around this issue on the forum, I found some older threads where people discussed that time scheduling did not properly stop ongoing connections or that NAT acceleration needed to be disabled (I do not see an option to do that on my router) but I could not see any post describing an issue similar to mine.

Cheers,
Josh

 

[tekrich]

This happened very early on in ownership of my AX88U. I put up with this for months.

Then I decided to reset the router and default to factory settings. The last bit here is important, defaulting the settings.

Once this was done, I had to set the router up again but the scheduling works now.

 

[Natty]

When searching around this issue on the forum, I found some older threads where people discussed that time scheduling did not properly stop ongoing connections or that NAT acceleration needed to be disabled (I do not see an option to do that on my router) but I could not see any post describing an issue similar to mine.

Parental controls time scheduling does not work reliably unless NAT acceleration is disabled. There is a link to the NAT acceleration switch from the AiProtection - Time Scheduling tab, where it says "Please disable NAT Acceleration for more precise scheduling control." The switch itself is located in LAN - Switch Control - NAT acceleration. When disabled, NAT traffic is handled by the CPU, enabling a time schedule to be applied.

I can confirm that time scheduling is working on my RT-AC66U-B1 after updating from 384.16 to 384.17 to 384.18 without resetting to factory default. It is in wireless router mode without any AiMesh system. Disabling hardware NAT acceleration has no measurable impact on throughput from my 100Mbps internet service, though presumably throughput will be impacted for much higher speed WAN connections, such as 1000Mbps.

 

[ChatmanR]

Where can I find this on the Merlin powered RT-AC86U?

 

[Natty]

Sorry ChatmanR for late reply but I don't have AC86U. It may be similar to AC68U-B1, where you would go to: AiProtection - Parental Controls - Time Scheduling. The disable NAT acceleration link is there in yellow.

Click on the NAT Acceleration link and it takes you to the NAT Acceleration setting in LAN - Switch Control, which should be set to disable.

 

[Keefy]

I have this same issue. I have updates the NAT Acceleration to be disabled. This did not fix the issue. The DSL-AC68U shows on the Client list through the web interface that the device in not blocked to the internet at the time its meant to allow but the device still cant get internet.

The curve ball may be that the client is connecting through a TR-AC67U and is using AiMesh.

Has anyone else seen this?

I am not using the merlin FW. I am on version;

DSL-AC68U	Current Version : 3.0.0.4.386_38832-ge7b654d Manual firmware update : Upload
AiMesh Node
RT-AC67U ( A8:5E:45:9A:58:40 ) Location : Living Room	Current Version : 3.0.0.4.385_20632-gfc5326d Manual firmware update : Upload
RT-AC67U ( A8:5E:45:9A:5A:C8 ) Location : Garage	Current Version : 3.0.0.4.385_20632-gfc5326d Manual firmware update : Upload

 

[r0bbieNZ]

Hi Keffy - its a bug with 3.0.0.4.386_38832 Asus knows about it and should be fixed in the next release

Go into Parental controls and change the device to disable and then click apply

 

[Keefy]

Much appreciated. Will test and report back.

 

[CoreDump7]

I'm running 3.0.0.4.385.20630 (released 2020.8.14) on an RT-AC68U and I'm still seeing the problem, i.e. I have time scheduling enabled for a particular device (by MAC address) and NAT acceleration disabled, and the device continues to connect to the internet, even though the Network Map shows via the leftmost icon that it's supposed to be blocked. Another curiosity is that this device is shown with a static IP even though the router is not assigning it one, and the second to left icon says that 3 devices are connecting through this IP.

2 questions: How does one find router bug reports of which ASUS is aware and planning to fix? What's causing the report of multiple devices connecting through this IP?

 

[L&LD]

@CoreDump7, have you tried any of the troubleshooting steps below?

Troubleshooting 101 Asus/RMerlin Routers 2020

Top 10 Simple Asus/RMerlin firmware powered Router Troubleshooting steps to try first: NOTE: Although this is for Asus/RMerlin-firmware powered routers, the steps below may be relevant to all routers, to get to a quick fix for common symptoms. Check that the router’s System Time is accurate on...

www.snbforums.com

 

[r0bbieNZ]

I'm running 3.0.0.4.385.20630 (released 2020.8.14) on an RT-AC68U and I'm still seeing the problem, i.e. I have time scheduling enabled for a particular device (by MAC address) and NAT acceleration disabled, and the device continues to connect to the internet, even though the Network Map shows via the leftmost icon that it's supposed to be blocked. Another curiosity is that this device is shown with a static IP even though the router is not assigning it one, and the second to left icon says that 3 devices are connecting through this IP.

2 questions: How does one find router bug reports of which ASUS is aware and planning to fix? What's causing the report of multiple devices connecting through this IP?
View attachment 25997

Its showing that because the time scheduling is on that device so thats normal - ill raise the time scheduling issue with Asus and see if I hear back

 

[CoreDump7]

Thanks for the responses. It took me a while to fully follow up on this. Doing a factory reset via the single reset button on the back didn't fix it. Today I did a "hard factory reset" by holding down the WPS button on power up until the power light stops flashing. I expected the router to come up with the old factory installed firmware, but instead it came up with the latest version (385.20633), including a captcha on admin login which I hadn't seem before. I then reconfigured (changed subnet, restricted DHCP to 2-99, set some manual addresses outside that range, turned off NAT acceleration, changed DNS servers) and then setup time scheduling for the device that was previously escaping it. It appears to work now: the device MAC shows as blocked on the router admin web page and the device itself (recent model HP chromebook) is displaying a blocked page on attempted WAN access.

BTW, another peculiarity of my network is that I have 2 other ASUS routers in Access Point Mode, connected via CAT5 wiring, to cover a larger area with multiple WIFI networks. Devices move from one network to the next as they are carried around, but the DHCP and device management should all be done by the single device in Router Mode.

I'll follow up if blocking fails again as it did before.

 

[ColinTaylor]

Devices move from one network to the next as they are carried around, but the DHCP and device management should all be done by the single device in Router Mode.

So what is your question/problem?

 

[CoreDump7]

@ColinTaylor :

There is a device for which I am attempting to do time scheduling (i.e. block on schedule) under AIProtection. Previously (Sept 5 post, above) the admin interface indicated that time scheduling was applied and the device was blocked, but it was connecting to the WAN anyway, and traffic analysis (correctly) showed it accessing at all hours, regardless of the time schedule. This persisted under firmware updates and deleting/recreating time scheduling rules. The problem seems to have been fixed by doing a hard factory reset (which coincidentially updated to a newer firmware). I assume the problem was due to a bug in prior firmware versions. Only time will tell whether it is still present in the new firmware. I'm providing lots of info in case ASUS is looking into the problem or someone else is experiencing something similar.

 

[CoreDump7]

There is a device for which I am attempting to do time scheduling (i.e. block on schedule) under AIProtection.

The problem is back: a chromebook is subject to time scheduling, the client list shows it as blocked, but it's able to do some tasks and gets recorded at the router as using a lot of bandwidth. I'm attaching the client list entry and the daily traffic analysis. There's not much breakdown. Most of the midday traffic should have been from zoom. Is it possible to get get a packet analysis similar to snort out of this router?

 

[CoreDump7]

I've now got a better idea what's going on. It looks like the parental control time scheduling is easily bypassed by explicitly assigning a non-leased IP address at the client. It appears that NAT works even on non-leased IPs while time scheduling blocking is based only on the DHCP server assigned IP.

I switched to the merlin firmware and installed tcpdump. Using tcpdump I found some youtube traffic flowing on a non-DHCP assigned IP address going to the ostensibly blocked device's MAC address. Testing on my own chromebook I was able to duplicate this behavior by setting up time blocking, waiting until the DHCP server assigns an IP to the device (which is then correctly blocked), then switching the chromebook from "Configure IP address automatically" to assigning it a random unused address in the subnet, at which point traffic begins to flow on the new IP address without blocking.

Questions: Can I disable NAT between non-leased IPs and the WAN? Is there a way to enforce time scheduling blocking based on local MAC address rather than IP address (if that's what it's doing)?

 

[tekrich]

... It appears that NAT works even on non-leased IPs while time scheduling blocking is based only on the DHCP server assigned IP.

This is interesting. Manually assigning an IP gets around the block. I'd be impressed with the users knowledge here to do this.

Would you get the same result if you manually assigned an IP on the router for the MAC address? Or block devices with a static IP? There has to be a way to stop this.

Also, after the time of the block, you could check for a device with a static IP that would appear in the list, to verify what's happening here.

 

[CoreDump7]

This is interesting. Manually assigning an IP gets around the block. I'd be impressed with the users knowledge here to do this.

Would you get the same result if you manually assigned an IP on the router for the MAC address? Or block devices with a static IP? There has to be a way to stop this.

Also, after the time of the block, you could check for a device with a static IP that would appear in the list, to verify what's happening here.

I'd be happy if my kid was actually learning how routers work in detail, but I suspect this trick came either from aimlessly fiddling with the settings while blocked, or via the grapevine.

I've played around with this a little more. Manually assigning an IP on the LAN > DHCP Server GUI page doesn't help. That appears only to affect the IP that the server gives out in response to a client request. There appears to be no enforcement of use of assigned IPs only. If a client simply starts using a LAN IP (that's not in use by another device), it looks like the router allows that, possibly after creating some kind of NAT table entry, if it didn't already exist. It's possible for one MAC to have multiple LAN IP bindings, and that's what the number superimposed on the device icon in the client list is indicating.

Without having (yet) tried to read the source, my suspicion is that the faulty behavior is due to tying AIProtection features to some kind of cached table of MAC/LAN-IP bindings, where enforcement is only done at a few discrete moments and/or only on the basis of a a single IP address. If there's a DHCP lease for a MAC then it looks like the AIProtection rules only apply to that IP, not any others the MAC might be using.

This looks to me like a fairly significant bug with more than one possible fix. Why does the router allow devices to use unassigned IP addresses on the LAN, and perform NAT for them? Why doesn't AIProtection apply to all IPs associated with a single MAC address? How and when are the AIProtection rules updated on the NAT translation table entries?

 

[tekrich]

Ah, bit of a typo in my previous post. I was meant to question if manually assigning IP via DHCP would work, but it doesn't, and you figured out the correct grammar.

Isn't there a way to add clients to the network via their MAC address? Where they will only be allowed only if added to the MAC list?

I'm thinking the only way is to set up a guest account for the user, and turn off the guest account manually. Then turn it on again in the morning.

Obviously you would need to change the password for the network already known.

 

[tekrich]

Just to add to this. Android and iPhones can now randomise their MAC address every time they connect to a network. This means dishing out a new IP and the said device will not be scheduled anymore.

I'm now looking at other solutions what will work.