NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Orbi RBR20 static route issue
Is this the right group for the RBR20 router? I'm having an issue where I setup a bunch of static IP address (with MAC address) under Setup / LAN setup, and then under Security / Access Control I have it set to turn on access control & Block all new devices from connecting. The issue is that sometimes the router will block one of the devices that I have setup under the static IP which seems like a bug. Has anyone run into this and knows how to fix it?
7 Replies
The title on this post is incorrect. Static Route refers to a router setting to direct connections to a specific IP range to a specific port. This is often used when the router is connected to a company network using a different internet connection. Using the LAN Setup to reserve specific IP addresses within the IP subnet for devices is called device reservation.
The first thing to check is that the device continues to present the same MAC address when it attempts to connect. Apple, Android, and many laptops now include a feature whereby devices present different MAC addresses under some circumstances. It is important to set the device not to do this when connecting to the home WiFi system.
p.s. Yes, this is the correct Forum for the RBR20 product.
Yes sorry I'm using device address reservation not static IP, and the devices aren't changing their respective mac address or IP address. So I asked this question to AI and explained what is happening and got the message below showing it is a known firmware bug.
On the Orbi RBR20, Netgear's Access Control firmware functions by actively tracking the connection states of recognized devices. When a device drops offline for a week or two, a glitch in the background code causes the router to handle its state incorrectly:
1. The State Desync: When your device went offline for two weeks, the router marked its profile as "offline." However, the firmware failed to properly retain its original "Allowed" state flag in the offline cache.
2. The "New Device" Trigger: When the device woke up after a couple of weeks, it requested its reserved IP address from the DHCP server. Because the Access Control backend code had corrupted its historical profile status, the firewall processed the incoming connection as a brand-new, unknown device.
3. The Automatic Lockout: Because your Access Control is configured with the strict global rule to "Block all new devices from connecting," the Orbi automatically applied a block to the device's MAC address—overriding your active IP reservation list.
This confirms your original suspicion: it is absolutely a firmware bug. The router should look at your permanent IP address reservation and remember the MAC address, but the Access Control sub-system loses track of the device's validation state during prolonged inactivity.
I asked this question to AI and explained what is happening and got the message below showing it is a known firmware bug.
FWIW, I get a very different answer from Chrome in AI mode when I ask it your question. The query was copied from your first post (w/o the first sentence).
- Randomized MAC Addresses (Most Common): Modern operating systems like iOS, Android, and Windows 10/11 have a default security feature called "Private Addresses" or "Randomized MAC addresses". If a device randomly rotates its MAC address, your router views it as a completely brand-new machine. Because it does not match your static reservation list, the "Block all new devices" rule instantly targets and blocks it.
- The Firmware Race-Condition Bug: Many consumer routers suffer from a firmware bug during system restarts or IP lease renewals. The Access Control system occasionally loads and enforces the "Block All" rule a few seconds before the LAN DHCP static reservation table completely initializes into memory. As a result, the router temporarily sees your legitimate device as "new" and flags it as permanently blocked.
- Hardcoded Software Limits: Older iterations of router management software have an invisible cap (often exactly 25 or 32 devices) on the total number of entries allowed in the Access Control table—including disconnected legacy devices. Once your network exceeds this limit, the system behaves erratically and begins dropping allowed devices off the list.
Looking at the AI sources (which btw is always a good idea), the firmware race condition posts are on a community thread here for a different router. Still conceivable - but nothing you can do about it, since your Orbi is long end-of-life.
The hardcoded-software limits also traces to a post here related to the Orbi RBK50, so perhaps relevant. But in that post, the OP thought the hard-coded limit was in the Netgear Genie app which is no longer offered. That said, the analysis is speculative - no affirmation from Netgear or other community members. There is a similar post which doesn't mention Genie for the RAX45 router - the invisible limit idea was offered speculatively there also, and there is no confirmation of what the limit was for that particular router.
Are you certain you've ruled out the randomized MAC address root cause?
AI is a useful tool, but not always entirely accurate. I have an Orbi WiFi5 router similar to the RBR20.
It might be helpful to examine the tables in the Access Control page. There are three tables:
- Devices that are currently connected to the network.
- Devices that are "Allowed" but are not currently connected.
- Devices that are "Blocked" and are not currently connected.
How can a device be "Blocked" and still connected? This is one of the strange things about networking. Suppose, for example, a device with an Ethernet adapter is physically plugged into the network. i.e. it is physically "connected". This is simply a fact. It can communicate using the Layer 2 Ethernet with other devices that are connected to the system. If it is "Blocked", then what it cannot do is communicate with devices where the communication requires it go pass through the router. A device can also be "connected" to the system using WiFi. i.e., it presents the correct WiFi credentials, so it is "connected". HOWEVER, when it attempts to communicate, it gets Blocked.
Of course, if the user happens to CLEAR table 2, then when a device connects again, it will be "New" and thus blocked.
My guess is that the "bug" is that the system does not interpret a device having an entry in the LAN reservation table as indicating whether it is "new" or "not new". i.e. when Access Control is enabled, the system might do this:
- Device connects (Ethernet or WiFi) and issues a DHCP request.
- Router looks in the LAN reservation table. Sees an entry for that MAC address and assigns an IP.
- Router then sees that Access Control is Enabled and checks, "is this MAC address in Table 1 or Table 2?" If so, the device is "Allowed". If not, the device is "Blocked".
"bug"? probably. Netgear going to fix it? not likely. These systems are End of Life.
p.s. Except for experiments, I do not enable Access Control.
Yes I am certain I ruled out randomized MAC address, so after all this and since the router is quite old I bought a new Wifi 7 router. I'll be getting that configured this weekend and hopefully this issue will be over as it's been quite a nuisance. I originally bought the Orbi as it was supposed to have the best range back then, but pretty sure a new Wifi 7 router will still be just as good and probably better.
but pretty sure a new Wifi 7 router will still be just as good and probably better.
Power limits haven't changed, so there won't be any improvement in max range. Throughput at distance could be better for devices that support the improved modulation.
Yes I am certain I ruled out randomized MAC address
Ok. You didn't say, so I wanted to confirm.
If you don't use parental controls, then maybe turn off ACL. It has no real security benefit.
