Why doesn't router enforce use of assigned LAN IPs?

[CoreDump7]

RT-AC68U: In debugging why time scheduling wasn't working for a device I discovered that a client device is not required to use the local IP assigned by the router (either via DHCP or manual registration), and instead if a client just starts using an unused IP in the correct subnet the router will go ahead and perform NAT to establish and route connections to the outside. This bypasses the time scheduling block and I suspect it may cause other problems with monitoring and filtering. I've not been able to find any discussion of this issue in the forums (so far...).

Can someone explain why the router allows clients to use IP addresses that they have not been explicitly assigned, or how to configure the router to enforce that restriction?

 

[dave14305]

The router’s DHCP server offers IPs to clients that request them. If a client configures a static IP (meaning DHCP is disabled), the DHCP server is not involved and the router has no obvious way to differentiate an intentional static IP from a sneaky static IP.

That said, time scheduling is based on MAC address, so IP should not matter. But if the machine is able to do MAC randomization (like iOS 14 and Windows 10 are capable of), then this may be what’s happening. Different MACs would get different IPs from the DHCP server.

 

[CoreDump7]

The router’s DHCP server offers IPs to clients that request them. If a client configures a static IP (meaning DHCP is disabled), the DHCP server is not involved and the router has no obvious way to differentiate an intentional static IP from a sneaky static IP.

One way might be to use the DHCP server table of leased IPs and manually assigned IPs to validate IPs against MAC addrs at connection establishment time and reject NAT on any IP/MAC that's not declared there. I'm guessing there may be cases where this would cause problems, but maybe it's feasible and useful as an option for some networks.

That said, time scheduling is based on MAC address, so IP should not matter. But if the machine is able to do MAC randomization (like iOS 14 and Windows 10 are capable of), then this may be what’s happening. Different MACs would get different IPs from the DHCP server.

My experiments on the RT-AC68U indicate otherwise. I'm able to evade blocking via the parental control time scheduling mechanism by unilaterally changing the IP at the client after a block interval has begun. tcpdump on the router shows that the new IP address is still using the declared MAC, and the traffic analyzer stats page which breaks down traffic by MAC shows the block-evading traffic on the correct MAC.

Issue with Parental Control - Time Scheduling

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...

www.snbforums.com

 

[dave14305]

My experiments on the RT-AC68U indicate otherwise. I'm able to evade blocking via the parental control time scheduling mechanism by unilaterally changing the IP at the client after a block interval has begun. tcpdump on the router shows that the new IP address is still using the declared MAC, and the traffic analyzer stats page which breaks down traffic by MAC shows the block-evading traffic on the correct MAC.

True, even though the input field refers to MAC, the resulting iptables rules use IP. Strange to me, but I don’t use this feature. More research required.

 

[CoreDump7]

True, even though the input field refers to MAC, the resulting iptables rules use IP. Strange to me, but I don’t use this feature. More research required.

My assumption is that there's a local-IP + MAC table maintained by the mechanism doing NAT, and that the time schedule blocking feature is imperfectly integrated so that not enough checking is done when creating entries in this table. I've just started reading the asuswrt source code and have not yet found any such table. Pointers to the relevant code or any design docs would be greatly appreciated.

 

[ColinTaylor]

True, even though the input field refers to MAC, the resulting iptables rules use IP. Strange to me, but I don’t use this feature. More research required.

That's very strange. It always used to be based on MAC address so I don't know why/when it changed. For example see this post from just 3 months ago: http://www.snbforums.com/threads/disable-internet-access-via-command-line.64861/post-605166

 

[ColinTaylor]

That's very strange. It always used to be based on MAC address so I don't know why/when it changed. For example see this post from just 3 months ago: http://www.snbforums.com/threads/disable-internet-access-via-command-line.64861/post-605166

OK, to try and answer my own question, from a cursory search on the source code it looks like the blocking is done by MAC address unless you're using AiMesh when it's done by IP.

https://github.com/RMerl/asuswrt-me...01cbcba3/release/src/router/rc/pc_block.c#L37
https://github.com/RMerl/asuswrt-me...fd92101cbcba3/release/src/router/rc/pc.c#L622

@CoreDump7 Are you using AiMesh?

 

[sbsnb]

My experiments on the RT-AC68U indicate otherwise. I'm able to evade blocking via the parental control time scheduling mechanism by unilaterally changing the IP at the client after a block interval has begun. tcpdump on the router shows that the new IP address is still using the declared MAC, and the traffic analyzer stats page which breaks down traffic by MAC shows the block-evading traffic on the correct MAC.

Have you tried working the rule in reverse, i.e., everyone is limited to certain hours except certain MAC addresses?

EDIT - I see that the router doesn't offer the ability to do that via the GUI.

 

[SomeWhereOverTheRainBow]

OK, to try and answer my own question, from a cursory search on the source code it looks like the blocking is done by MAC address unless you're using AiMesh when it's done by IP.

https://github.com/RMerl/asuswrt-me...01cbcba3/release/src/router/rc/pc_block.c#L37
https://github.com/RMerl/asuswrt-me...fd92101cbcba3/release/src/router/rc/pc.c#L622

@CoreDump7 Are you using AiMesh?

A simple solution is for you to attempt to add the clients to no roam between aimesh nodes under wireless settings. This may force the device to only connect to the parent router, maybe allowing for Mac blocking. Try it out. Idk if this is the case though. Just a shot in the dark.

 

[CoreDump7]

OK, to try and answer my own question, from a cursory search on the source code it looks like the blocking is done by MAC address unless you're using AiMesh when it's done by IP.

https://github.com/RMerl/asuswrt-me...01cbcba3/release/src/router/rc/pc_block.c#L37
https://github.com/RMerl/asuswrt-me...fd92101cbcba3/release/src/router/rc/pc.c#L622

@CoreDump7 Are you using AiMesh?

Well, I was about to answer "No, I'm not using AiMesh" but then I looked at the admin page, and things seem to have changed. I'm running the merlin 384.19 release from August. I have 3 ASUS router/basestations joined by an ethernet switch to cover a large house. Two of them are in access point mode and the master used to be in ordinary (non AiMesh) router mode, but it looks like that option has gone away. It looks like there's no longer a non-AiMesh router mode. Without existence of another router in AiMesh Node mode it's not really AiMesh, but it looks like maybe some of the AiMesh-necessary functionality is only guarded by compiler switches and not runtime configuration.

Note that the code around pc_block.c:36 which is guarded by RTCONFIG_AMAS appears to check for the existence of a MAC/IP binding in the DHCP server and if it finds one, it builds the blocking rules that go into the nat_rules file using an IP rather than the MAC address. This appears to be the point at which the wrong behavior is being selected.

Is there a firmware build without AiMesh that I should be using?

It looks to me like it would be useful to have some runtime detection of whether an AiMesh node is actually in use, and avoid all AiMesh-specific logic in that case.