iOS 14 and blocking those pesky "private addresses"
-
The iOS 14 devices on my home network are annoying me with their private addresses (MACs) dancing all around.
I'm thinking about using a floating rule to allow outbound traffic only from a list of known MACs. I'd then require the iOS devices to turn off "private address" for that particular wireless network.
My ARP table has 58 local addresses. My hardware is at 3% CPU and 31% memory. In my mind I've got power to burn.
What do you guys think about all this?
Explanation of this iOS 14 feature with maybe a little extra info you may not have seen before ...
To reduce privacy risk, iOS 14, iPadOS 14, and watchOS 7 use a different MAC address for each Wi-Fi network. This unique, static MAC address is your device's private Wi-Fi address for that network only.The introduction to the feature is mentioned in the "Build trust through better privacy" video (https://developer.apple.com/videos/play/wwdc2020/10676/).
Key points :
Users are always in control - users can control enablement of the feature at any time for each network.Addresses are generated randomly for every network
Addresses are not linked to your identity
Addresses are updated for all networks daily by the device, NO server is involved in address generation. Since addresses are generated randomly, it is very unlikely that two devices on the same network will generate the same address.
A new MAC will be used whenever a new address has been generated and the device re-joins the network
Users can see which MACs are generated for each network in the Wi-Fi scan list, even before joining the network
Networks that use MAC-based access inherently track devices. Privacy on tracking networks can be controlled using the temporary address so that participation with the tracking network is also temporary.
-
Just switch it off on the iDevices, you're over thinking the problem.
-
I hear you, but, when they turn "private address" back on I'll have to start chasing my tail again.
-
@timtrace said in iOS 14 and blocking those pesky "private addresses":
'm thinking about using a floating rule to allow outbound traffic only from a list of known MACs. I'd then require the iOS devices to turn off "private address" for that particular wireless network.
How are you going to filter by MAC address? pfSense (and most firewalls) do not support that kind of filtering as MAC is Layer 2 and firewalls generally work at Layers 3 and up. I think you can do some MAC filtering using Captive Portal, but most folks don' want to use Captive Portal on their home LANs. Guess you could, though.
-
@bmeeks said in iOS 14 and blocking those pesky "private addresses":
How are you going to filter by MAC address? pfSense (and most firewalls) do not support that kind of filtering as MAC is Layer 2 and firewalls work at Layers 3 and up.
I can use a DHCP reservation to enforce an IP which can be added to an alias.
I actually have the captive portal running, and our work and school devices connect there, as well as any guests. I had to change from using "allowed MACs" to "allowed hostnames."
-
@timtrace said in iOS 14 and blocking those pesky "private addresses":
@bmeeks said in iOS 14 and blocking those pesky "private addresses":
How are you going to filter by MAC address? pfSense (and most firewalls) do not support that kind of filtering as MAC is Layer 2 and firewalls work at Layers 3 and up.
I can use a DHCP reservation to enforce an IP which can be added to an alias.
Yeah, but you don't need a floating rule for that. Just an alias used as "source" in an inbound rule on say the LAN.
Might wind up being a pain in the butt if the iOS devices insist on using the private addresses when enabled and don't get an IP using the defined MAC.
If it's a home network, why is it such a problem? I only see it as an issue if you have really small DHCP address pools and long lease times.
-
@timtrace said in iOS 14 and blocking those pesky "private addresses":
when they turn "private address" back on I'll have to start chasing my tail again.
Your tail ?
They were cutting in their own tail. They break things with their actions, what's against saying : they should undo their own actions ?Just an example : you bought a car that runs on petrol.
You fill it up with gasoline for what ever reason.
I guarantee you that the garage where you bought your car won't get upset. They might even smile. Because they are applying the golden rule : "You fckd up => you pay".As you said : enforce DHCP leases with upfront known MAC addresses :
Activate :
login-to-viewinitially, this option will needs you to enter each known MAC of each device ( !! ). It will deal with the ever changing MAC addresses.
Then, there will be no more "they turn it on" because they wouldn't be able to connect any more.The very basics of a captive portal is :
"Enable Internet access to a group of unknown devices/people."
These people would need to have some authentication credentials, like a user ID and a password. That's it.
IP .... MAC .... why should / would you care ? You gave them access credentials, people with unknown devices. They can even share devices, use multiple devices or even share the connection among them.Another example :
Banks hands out credit cards. An PIN codes.
Believe me : a bank doesn't care who - the person - is using the credit card and PIN code. When transactions show up using the card and the code, the bank takes the money from your account. Again : the person who initiated this transaction is unknown. Typically : it should be you. If it wasn't you, it's still you that initiated the fact that some one else initiated the transaction. So it's you.
You got my point : the real card 'owner' will cooperate with the rules (which he agreed upon, otherwise he wouldn't even have that card).
So all ends happily.Important is : keep it simple for both sides ;)
-
@timtrace said in iOS 14 and blocking those pesky "private addresses":
I'm thinking about using a floating rule to allow outbound traffic only from a list of known MACs.
Pfsense doesn't filter on MAC addresses. You have to use IP addresses.
-
@bmeeks said in iOS 14 and blocking those pesky "private addresses":
How are you going to filter by MAC address? pfSense (and most firewalls) do not support that kind of filtering
Linux based firewalls running IPTables do.