iOS 27 BYOD and Smoothwall web filtering - Connectivity Assist causing issues?

[Smokebomb]

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 September 17 by Smokebomb

[PaddyNewman]

Interesting. Ive just got ios27 - will give this a whirl. I would presume you block all other DNS regardless?

[ZeroHour]

1 hour ago, PaddyNewman said:

I would presume you block all other DNS regardless?

I wondered that too, I would block all other DNS outgoing.

[Smokebomb]

I can confirm all other DNS is blocked. @PaddyNewman if you get chance to test, please let me know if you see similar behaviour in your environment with iOS 27 - at least then I'll know it's not just us!

[PaddyNewman]

Looking at this from an iPhone perspective as my iPad has no cellular, its sending the request through 4G looking at the mobile data... Wonderful move Apple. Turning it off breaks things as expected and no 4G data appears to take place, but sending it via Connectivity Assist just offloads the failure to 4G and boom, connected.

 

Can only see the fix being MDM payloads which aren't great for BYOD as its not your device to manage. I havent tried decrypted traffic yet, but will assume a similar pattern of can't get there, try the other way. 

 

The other amazing move by Apple - "Connectivity Assist is on by default", much appreciated. 

[synaesthesia]

Joys. We do full decryption on BYOD otherwise we're not KCSIE compliant, haven't looked at DNS tomfoolery yet though (and looks like it might be a good thing we didn't!).

So would this also then have an effect on MITM setups?

[Smokebomb]

Enabled a decrypt and inspect policy that targets a specific location that includes my test iPhone; jumped through all the hoops to get the cert installed and trusted and yes - webpages are now filtered correctly. However, if I don't go through the motions to get the root cert on (or if I turn the root certificate trust off), browsing works fine anyway, including to sites that should be blocked! I can see this traffic in the Smoothwall filter logs, again highlighted in red but its allowed through due to whatever internal mechanism Apple have put in place with this new feature. If I turn connectivity assist off, I can't browse anywhere without ongoing "this connection is not private" warnings in Safari (which was the old, expected behaviour) - this new feature is really going to cause havoc with KCSIE compliance. @tom_newton - are Smoothwall aware of this?  

[tom_newton]

Thanks for the detailed explanation - is this traffic breaking out QUIC on udp/443?

 

 

[Smokebomb]

Hi Tom, no - we have a firewall rule in place to block all QUIC traffic.

[PaddyNewman]

Mine is the same, tried browsing to various sites, 888, Surfshark etc. With the toggle on, I get a deny log (In Netsweeper, not Smoothwall but at this point if feel its going to be vendor agnostic) then browser just throws out of 4G.

 

I only have TCP 80 443 and DNS to our DNS, I operate on a very locked down firewall, but its using 4G to dip out.

Edited September 21 by PaddyNewman

[Smokebomb]

Agreed, this is probably going to hit every vendor's solution. If it was just going out via the users 4G/5G connection and completely bypassing the Smoothwall that wouldn't be so bad; unfortunately the awkward bit is that the traffic is still showing up in the Smoothwall real-time log - so if it is being seen/logged on the transparent proxy does that mean the duty of care still lands with us? I suspect so 

[Smokebomb]

Info on how this new feature works is scarce, but NordVPN put up this post about it: Scam and phishing protection on iOS 27 | NordVPN Key quote: 

 

Connectivity Assist uses cellular data alongside Wi-Fi when it decides your Wi-Fi connection isn’t working well. When real-time protection blocks a domain, iOS can read that block as a potential connection problem.

 

Connectivity Assist then uses cellular data to look up the website address again. That request goes to your carrier’s DNS servers instead of NordVPN’s. If the lookup succeeds, the blocked site may load.

 

Every blocked domain is looked up separately, so the issue can affect not just phishing sites but also ads and trackers on otherwise normal pages. You stay connected to Wi-Fi throughout, and your settings still show that real-time protection is on, even though some requests bypass it entirely.

[Smokebomb]

Ok, so given the above info I've done a bit more testing. If, under Settings > Wi-Fi > Connectivity Assist I tap "reset data usage" and browse to say bbc.co.uk then Connectivity Assist shows no usage of data. Then I go to 888.com, the page loads and I can see 435 KB of data usage. So it appears that Smoothwall blocks the banned gambling site, iOS interprets the block as an error, than reloads the page using mobile data. That's a little more reassuring, but it is going to cause confusion for safeguarding teams as they will be coming to us asking why sites aren't blocked.

Edited September 21 by Smokebomb

[PaddyNewman]

9 minutes ago, Smokebomb said:

Ok, so given the above info I've done a bit more testing. If, under Settings > Wi-Fi > Connectivity Assist I tap "reset data usage" and browse to say bbc.co.uk then Connectivity Assist shows no usage of data. Then I go to 888.com, the page loads and I can see 435 KB of data usage. So it appears that Smoothwall blocks the banned gambling site, iOS interprets the block as an error, than reloads the page using mobile data. That's a little more reassuring, but it is going to cause confusion for safeguarding teams as they will be coming to us asking why sites aren't blocked.

Exactly what I was seeing. This is not great. 
I would note though... I would just be on 4G as a student anyway so its sort of always been a problem. The biggest one here is the illusion of connected to school = safe and filtered.

 

Very much an annoyance.

[PaddyNewman]

Weirdly I just threw it through a bind server with nxdomain for the 2 icloud URLs and I have really upset the device. Will test again when I can grab the iPhone but I got no bypass with the relay showing as unavailable and the connectivity assist on, my logs show it hitting the filtering system multiple times rather than once so the browser didn't attempt to go round the back this time.

I need to hit it harder and see what happens, I hate it when its not consistent.

[tom_newton]

Hmm, I wonder if we could run a different block.... there is, I think, still a block-by-drop which would present a different looking failure mode to IOS, but I suspect it wont help.

Of course having the cert installed makes the block look successful: you get content from a domain you trust that is 200, and has size.

 

 

[synaesthesia]

Keeping a close eye on this - as it stands it appears as if there's no choice but to remove newer IOS devices from BYOD and guest networks until there's a workaround/solution.

[stgoodyeara]

Just giving this post a little "nudge"

 

Has anyone had official word from smoothwall even acknowledging they can no longer filter BYOD if it has a cellular connection? I think DSLs need to know this, the safeguarding implications for some vulnerable students that may have iOS27 devices shouldn't be overlooked.

[tom_newton]

Working on it - apple appears to have made life very difficult for all filter vendors with this. Are you using block-by-drop, or a redirect to a blockpage?

[stgoodyeara]

Mixture depending. Social media is block by drop otherwise the web server that renders the block page cripples resources on the appliance.