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.

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.

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

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

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?

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!

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!)

Just a quick heads-up for anyone using Smoothwall Cloud Filter. While working with Smoothwall support on a recent ticket, we discovered that the "Malware and Phishing" category is not currently supported by the Cloud Filter. This means that even if you add it to your blocklists, sites won’t be classified under this category in the browser extension — and as a result, they will still be allowed. According to Smoothwall, this is due to the size of the category causing performance issues within the browser extension so they have excluded it. It’s worth noting that this category does still work as expected on on-premise appliances, so traffic filtered there will be blocked correctly. In the meantime, you may want to: Add any known malicious URLs to a custom block category. Ensure you have other anti-malware/web protection controls in place to cover the gap. Hope that helps others avoid the same confusion.

Another tip, where possible apply configuration/apps to the built-in "All Devices" group, then use assignment filters (found under "Tenant Administration") to refine the targeting. For instance, we add an "exclude" filter for Personal Devices. Performance recommendations when using filters | Microsoft Learn

If you have access to the 365 admin centre, there is a current Intune health issue that could be responsible: https://admin.cloud.microsoft/?#/servicehealth/:/alerts/IT1142323 This has been affecting us since Friday, with no devices checking in and app/configuration deployments not updating in the admin dashboard (though there is some evidence from checking PCs locally that installs are still happening). Device check-ins started working again late last night, but app/configuration deployments are still not showing any new data in our tenant. Here's the full blurb: Some users' newly enrolled devices aren't appearing in the Microsoft Intune portal Issue ID: IT1142323 Affected services: Microsoft Intune Status: Service degradation Issue type: Advisory Start time: 22 Aug 2025, 17:00 BST User impact Users' newly enrolled devices aren't appearing in the Microsoft Intune portal. More info New devices enrolled after Friday 22 August 2025 at 17:00 BST , may not show in the Microsoft Intune portal. Additionally, users see stale data for co-managed Intune Advanced Analytics device reports based on certain scope tags. Scope of impact Your organization is affected by this event, and some users’ newly enrolled devices may be impacted. Root cause A section of infrastructure which reports newly enrolled devices is performing below acceptable performance thresholds. Current status 27 Aug 2025, 08:44 BST We’ve verified that the previously identified root cause is indeed responsible for impact. We’re continuing to work through the backlog to fully resolve the issue. Next update by: Wednesday 27 August 2025 at 19:30 BST

Looks like the August cumulative update will fix this issue. Listed under the “Improvements” section of the release notes: Authentication] Fixed: This update addresses an issue that caused delays during sign-in on new devices. The delay was due to certain preinstalled packages. https://support.microsoft.com/en-gb/topic/august-12-2025-kb5063878-os-build-26100-4946-e4b87262-75c8-4fef-9df7-4a18099ee294

Do the PCs have the July 2025 cumulative update installed? We're seeing this behaviour with new user logins since that was installed, and checking the event log we can see errors relating to universal app provisioning that seems to be slowing down the first login. I've seen this reference to similar behaviour in a reddit thread for the July patches:

We get around this exact situation using logon scripts. We store the powershell scripts in azure blob storage, then create a scheduled task (via a remediation script) that runs the script direct from that source at user logon. The scripts contain any reg values that we need in place straight away such as browser home pages, office settings, filter configuration, mapped drives, and printer mapping.

There are open source scripts out there. Bear in mind that these all use the webDAV protocol for the file transfers which is what Cloud Drive Mapper has just moved away from due to its limitations around speed, integration with File Explorer progress bars, file size limits, and inability to get around throttling that Microsoft may apply to your org: OneDriveMapper | Liebensraum. Here's some really useful techie info on the underlying tech that Cloud Drive Mapper is using in their product these days (as you can tell, I'm a fan!) Cloud Drive Mapper (CDM) overview

We've had something similar going on, but discovered the accounts in question did not have the "Intune plan 1" license assigned to them in the MS365 admin centre. Once we assigned that license to them the issue was resolved. Maybe something similar with this account?