Jump to content

Recommended Posts

Posted (edited)

We use our Smoothwall appliance (Maiden-38) to filter BYOD devices. At the moment, we do not ask students to install the Smoothwall cert onto their personal devices due to the support overhead, so effectively just do DNS based filtering. With iOS devices, we "instruct" devices that support iCloud Private Relay (which a user gets if they pay for iCloud storage, and effectively bypasses DNS based filtering) that our network is incompatible with the feature. This is done with our internal DNS returning an NXDOMAIN for mask.icloud.com and mask-h2.icloud.com. The user gets a friendly notification via iOS that iCloud Private Relay is not compatible with this network and prompts them to turn it off for the SSID. So far so good, however iOS 27 seems to have added a new wrinkle to this. It now includes a feature called "Connectivity Assist" that can be enabled/disabled per SSID, but that is at the users discretion. From our research and testing, when this is turned on (as it is by default) the DNS server provided by the Wi-Fi network will be ignored and the DNS server that connectivity assist uses will be enforced instead. This means the phone never gets the "instruction" from our own DNS server to bypass iCloud Private Relay and the user can browse the internet unfiltered. The Smoothwall web filter log shows the user browsing to the restricted site (shows red highlighting in the log, but not denied). If we turn off connectivity assist, filtering works as expected - not sure our students are going to be willing to comply with that request though... 

 

Is anyone else observing this behaviour in their environment (appreciate it's early days for iOS 27!)

Edited by Smokebomb

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...