A device blocked by MAC address filtering usually means its hardware address is not on the router's allow list, was typed with a wrong character, or has been randomized by the client OS. Fix it by reading the real MAC from the device, adding it exactly to the whitelist, and disabling MAC randomization for that SSID.
Symptoms
- Specific device fails to obtain an IP address, while other clients on the same Wi-Fi work fine.
- Client authenticates against Wi-Fi but is immediately disconnected or shows "cannot connect to this network".
- Router log shows entries like "MAC filter drop" or "ACL deny" for the client's hardware address.
- Phone connects only when Wi-Fi "Private Address" or "Randomized MAC" is turned off.
- Newly added devices (guest laptop, IoT sensor, printer) never reach the LAN despite correct password.
Common Causes
Device MAC not on the allow list
Filtering is set to "allow listed devices only" and the new client was never added. Any device not explicitly permitted is silently dropped after association.
Typo in the whitelist entry
MAC addresses use hexadecimal, so 0/O and 8/B confusions are common. One wrong nibble means the router matches a non-existent device and blocks the real one.
Randomized / private MAC on the client
iOS, Android and Windows 10/11 default to a per-SSID randomized MAC. The address the admin whitelisted last month is not the address the phone presents today.
Filter applied to the wrong radio or SSID
Many routers keep separate ACLs for 2.4 GHz, 5 GHz and guest networks. A device whitelisted on 2.4 GHz can still be blocked when it roams to 5 GHz.
Deny list still contains the device
After switching from blacklist to whitelist mode, some firmwares keep the old deny entries active in parallel, so a previously blocked MAC stays blocked.
Step-by-Step Fix
- Confirm MAC filtering is actually the cause
Log in to the router admin UI (typically http://192.168.1.1 or the gateway shown by ipconfig / ip route). Open Wireless, Security or Access Control and note the filter mode: disabled, allow-list, or deny-list. Temporarily disable filtering and retest the client. If it connects, filtering is the cause; re-enable it before continuing. - Read the device's real, current MAC address
On Windows run `ipconfig /all` and use the Physical Address of the correct adapter. On macOS hold Option and click the Wi-Fi icon, or run `ifconfig en0 | grep ether`. On Linux use `ip link show`. On iOS check Settings, Wi-Fi, the (i) next to the SSID. On Android check Settings, About phone, Status or the SSID details. - Disable MAC randomization for this network
Randomized MACs defeat static whitelists. On iOS turn off "Private Wi-Fi Address" for the SSID. On Android open the saved network, Privacy, and choose "Use device MAC". On Windows 11 open Wi-Fi properties and set "Random hardware addresses" to Off. Then re-read the MAC; it will change after this switch. - Add the MAC to the correct allow list
In the router, open the allow list for the exact SSID and band the client uses. Enter the address in the format the router expects (colon, dash, or no separator) and paste rather than retype to avoid 0/O and 8/B typos. Give it a recognisable label such as "marie-laptop-wifi" and save. - Remove stale or duplicate entries
Delete the device's old randomized MACs from both allow and deny lists. If the router keeps a separate deny list, verify the current MAC is not sitting there from an earlier session. Duplicate entries across bands can also trigger inconsistent behaviour, so keep one entry per physical adapter. - Apply changes and force reassociation
Save the ACL, then reboot the router if the firmware requires it (many TP-Link, ASUS and FRITZ!Box models apply ACL edits live, others do not). On the client, forget the SSID and reconnect so it performs a fresh 802.11 authentication against the updated filter. - Verify against the router log
Open System Log or Wireless Log and filter for the client MAC. A successful join shows association, authentication, and DHCP ACK entries. If you still see "ACL deny" or "MAC filter drop", the address in the list does not match what the client presents; recheck randomization and re-copy the MAC. - Decide whether MAC filtering is worth keeping
MAC filtering is trivially bypassed by spoofing and adds operational overhead every time a device changes. For most networks WPA2/WPA3 with a strong passphrase, plus a separate guest SSID, provides stronger protection with less friction. Keep MAC ACLs only where an audit or policy specifically requires them.
Common MAC filtering symptoms mapped to likely cause and fix
| Symptom | Likely cause | Fix |
|---|---|---|
| Device authenticates then drops instantly | MAC not on allow list | Add current MAC to the SSID's allow list |
| MAC in whitelist keeps changing | Client uses randomized private MAC | Disable Private Address / random MAC per SSID |
| Works on 2.4 GHz, fails on 5 GHz | Separate ACL per radio | Add the MAC to both bands or use a unified ACL |
| Router log shows "ACL deny" | Typo or wrong separator in entry | Re-copy MAC exactly; match router's format |
| All new devices blocked | Filter mode set to allow-list only | Add each new device or switch to deny-list mode |
| Previously working device now blocked | Adapter replaced or MAC spoofed | Read the new physical address and update entry |
Prevention
- Maintain a shared spreadsheet of device name, owner, MAC and band so new admins can audit the allow list.
- Turn off MAC randomization on managed corporate devices via MDM before onboarding them to filtered SSIDs.
- Prefer WPA2/WPA3-Enterprise with 802.1X for access control; use MAC filtering only as a secondary layer.
- Review and prune the allow list every quarter to remove decommissioned or lost devices.
FAQ
Does MAC address filtering actually improve Wi-Fi security?
Only marginally. MAC addresses are broadcast in the clear in every Wi-Fi frame, so an attacker with a passive sniffer can read an allowed MAC and spoof it in seconds. Filtering is useful as an administrative control (who is permitted on this network) but it is not a substitute for WPA2/WPA3 encryption and a strong passphrase.
Why does my phone's MAC address keep changing?
iOS, Android 10+ and recent Windows builds generate a random MAC for each Wi-Fi network by default to reduce cross-network tracking. That means the address on the router's whitelist becomes stale as soon as the phone reconnects. Disable the "Private Address" or "Randomized MAC" option for the specific SSID you filter, then whitelist the resulting hardware MAC.
Can I whitelist a MAC range instead of individual devices?
Consumer routers almost never support MAC ranges or wildcards; each entry must be a full 48-bit address. Some business-grade access points and controllers (Aruba, UniFi, MikroTik) allow OUI-based rules, so you can permit an entire vendor prefix. For fleets of identical devices this is worth checking in the controller's ACL documentation.
Need help auditing your Wi-Fi access control? Talk to our network team.