What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

CoreDump7

Occasional Visitor
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?
 
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.
 
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.

 
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.
 
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.
 
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?
 
Last edited:
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.
 
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.
 
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.

Screenshot from 2020-10-20 13-04-14.png
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top