Private MAC in iOS 14 and auto-block new devices causes BAD_ADDRESS

mozarella

Hi,

in our office-network, we have a DHCP-Range between 192.168.xxx.1 and 200, quite a lot of IPs. Everything works fine. But now i'm in trouble because the DHCP-Scope is filled up with "BAD_ADDRESS"-entries, until the scope is filled up and DHCP doesn't offer IPs anymore.

During my research with logfiles (Windows Server 2008R2 as DHCP) i found out that the problem is caused by iOS 14's new option with private MAC-address + autoblocking new devices through fingbox.

Once a iOS-device with activated private MAC-address-option is connected to the network, fingbox is blocking this device and around 30 mins later, the DHCP-scope is filled up with BAD_ADDRESS entries.

When i check the logfiles of DHCP, i could see fingbox's MAC-address for each BAD_ADDRESS. So i'm thinking, a new device is asking about DHCP, the DHCP-server checkes if the possible IP is already "alive". In this case, fingbox will answer the ping-question and DHCP-Server is setting this IP to "BAD_ADDRESS".

I've set the lease-time down to 20 mins, but it seems that the BAD_ADDRESS-entries are "alive" for round about 60 mins.

I've found the option of conflict-detection, i've set to 0 (deactivated), but there are still BAD_ADDRESS-entries applying.

I can't deactivate the auto-block of fingbox, because lots of unwanted / unknown devices will connect. There's also no network-management to block devices within the network. Especially the new private-option is really bad for network-monitoring / -management.

So could it be possible that fingbox won't bind the new IP to itself? I've set the slow network detection option in fingbox already, but the problem is still present.

I've also set a delay of 150 ms within DHCP-server, same result, still flooding the scope with BAD_ADDRESS.

Does somebody else has this kind of problem? And maybe found any solution?

regards,

mozarella

Static

You’re not going to like this suggestion... but have a policy that iOS devices need to have this feature disabled. Request that end users present their device to have this turned off if they would like to be able to connect to the office’s wifi. (Assuming the devices are allowed on the wifi) This new feature while on the surface looks like Apple was getting ahead on security, however I also had a rude awakening to this feature and have been disabling it.

Lee_Bo

There are already several threads on this very subject.
Yes, like @Static said, you can ask and possibly force iOS users to turn that feature off and it will only be off for your wifi network, but we SHOULDN'T have to disable that feature.  IMHO, this all falls on Apple.  They made the change which, on the outside looks great, but we, you and I, the network admins, are the ones having to "fix" it.  There are several options you can do but you'll have to see what your company will and will not allow.  And like you, no, I AM NOT disabling "auto block new devices".  I abso-freggin-lutely love that feature and, unfortunately for Fing, is the ONLY reason I still have a Fingbox.

mozarella

Next problem is, our firm is splitted into more buildings crossover the village. All buildings are connected to each other over fibre and built up one big network. So there are some accesspoints with different SSID. So each SSID is a "own" wifi for iOS and one device should connect to each of this wifi and disable this feature. Normal users don't understand this feature and don't know what to do or don't know the background of "my" problem with this "feature".

I wish, apple will do a switch to turn on or off this feature global. Or ask if the connected wifi is public wifi (then activate automatically) or private / office wifi (then deactivate it).

I'm happy with fingbox, because it tells me whats going on within our network (two firms and 2 at home). A quick overview, especially when i'm not 100 % network admin. I really like to build VLAN and have a view inside unifi network through controller. But mostly there's not much time to fix a problem like this, or do long research.

Back to topic. I found a powershell-script which could clean up a DHCP-scope about devices which got "BAD_ADDRESS" entry. This sounds great, but it's not working on my 2008R2 server. I'm thinking that powershell extensions are made later, maybe in server 2012 or 2016. Any other idea how to clean up this BAD-ADDRESS entries automatically? Or deactivate the ip-check?

mozarella

As possible workaround i've set two options in our DHCP-Server. First i have expanded the range to 240 devices and second i have set the lease-time down to 20 mins. This will create some network-overhead, but unused leases would be released quicker than before. Though the "lease-time" of BAD-ADDRESS-entries is still around 1 hour, maybe an auto-delete built in?

I think a solution for the fingbox would be, blocking the new device after the dhcp-handshake is finished and the device got it's ip-address. Maybe set a time-window between recognize and block around 10 seconds.

pcsasd

Not very secure but a possible work-around. The iPhone will also have a name on the network which is the users name like Mozarellas iPhone. Fing should allow re-entry of such a name and a new MAC Address or at least have an option to exclude this from generating a BAD_ADDRESS flag.

mozarella

I'm proud that my thread was mentioned at the newsletter.

The "BAD_ADDRESS"-Entries are upcoming at the DHCP-Server, not within the fingbox / fing-account. Just to make this clear. Actually i think this will happen also without the new private MAC-address-feature, but with this feature built into iOS, the problem of supposed new devices which will be blocked, is doing this more stronger (especially when all iOS-devices doing update and coming up with new MAC).

But @pcsasd when i read your comment, i'm thinking at another thread i've startet a while ago. I've asked about a feature to merge multiple MAC-addresses into one device. In the past, i noticed that the same device with wifi and lan-port used randomly with one of these, will pop up in fingbox as two seperated devices. Actually it's one and the same device.

After i started this thread here, i read a  lot about iOS's private MAC-address-feature. So it seems that apple doesn't change the private MAC-address, it should be static per each wifi. So it'll be much more interesting to merge multiple MAC-addresses into one device (by hand ofcoz), because if there are a few different wifi accesspoints within one network, and if each accesspoint has another ssid, iOS doesn't know that it's the same network, iOS just see the different ssid's and will prepare different private MAC-addresses, one for each ssid.

So it'll be interesting, if fing will provide a feature to merge multiple MAC-addresses into one device. As @pcsasd mentioned, maybe the devices-name could be the key to figure out that it's maybe one and the same device. If auto-block is enabled, maybe the admin could be notified (as working already now) and be possible to allow / disallow or merge to an existing device.

fing is also collecting more data from each device, so there could be a kind of fingerprint including device's name, operating-system, model of device, running services... this will be more clear than just the device-name.

mozarella

I need to "reopen" this thread again.

The DHCP-Scope is filling up again with BAD_ADDRESS-entries. So I have done some research. The last IP which was branded with "BAD_ADDRESS" i've sent ping to (timeout ofcoz) and then i have done "arp -a" with that address. I've found out the MAC over this way (DHCP doesn't show the correct MAC for all these BAD_ADDRESS-entries). Fingbox told me that behind this MAC is a iphone which is blocked over fingbox. So i'm thinking that the blocking mechanism of fingbox cause the problem of lots of "BAD_ADDRESS"-entries in DHCP-Scope, isn't it? If there are some blocked devices, the DHCP-scope will fill up with that entries and finaly other devices won't get valid IP-addresses anymore because the scope is filled up.

I can't deactivate the fingbox's blocking mechanism, because unwanted devices will come up then. And changing SSID and / or pwd won't solve this problem.

MartynK

Did this ever get a successful conclusion ?

I am getting the same problem, but with new Windows 11 VMs.
When I create a new VM and it starts the process of going through the Windows initialisation, asking for regions, usernames, machine name etc, I find it cannot get an IP.

When I then go to my Microsoft DHCP server I see all available addresses now are defined as BAD_ADDRESS.
The only way I can get around this is to turn off notifications during the install process.

Help