Global Protect on IOS Always ON VPN sanity check

[ivormthomas]

I've had a Palo Alto case open for almost 9 months now that appears to have devolved into a finger pointing match between Apple and PAN and I'm going to have to make some decisions here, I don't know if anyone else uses that functionality or not.  Apple re-wrote the VPN APIs around IOS version 12.1 where they only allow "Connect on demand" (AKA Always on VPN) VPNs on Certificate based VPNs and only allow Certificate based VPNs on Corporate enrolled devices using a mobile device management platform to distribute the certificates and values.  I meet the requirements and while it was poorly documented on now to set this up, I got it working and thought all was good until IOS 15.1 came out; the issues have continued in every IOS release since then, older IOS devices that can't upgrade to version 15 have no problems.

Once IOS 15.1 came out, "Connect on Demand" fails to connect on IOS reboot (deliberate or discharged battery, makes no difference) and what has always been true is that once connect on demand is enabled, an iPad will have no network connectivity on any network (cellular, Wi-Fi, etc.) until the VPN is connected.  What Apple seems to have forgotten to do is allow network access from the device to the mobile device platform when the VPN can't connect so that if the certificate is expired and the profile needs to be updated, the user doesn't remember their password and needs a reset from the MDM, or the device is lost or stolen and we need to remote wipe or obtain geolocation data-- we have no access once the device is rebooted.

For now, we've had to weaken our IOS password policy so fewer people forget (they can manually start GlobalProtect after the unlock post reboot) and if they can't unlock it, we have to do ten bad passwords over 8 hours to automatically wipe the devices for us to set them back up again-- if one is lost or stolen and the battery goes dead, we'll never find it and have to hope the password was good enough after we weakened them because of this defect. 

Apple's official statement to the GlobalProtect team seems to be, "no one should have access to the certificate keychain" while the device is locked and again, meaning GlobalProtect can't start after reboot, and there is no MDM communication when GlobalProtect isn't connected.

Has anyone else seen this and figured out something I'm not seeing?

[BPry]

@ivormthomas,

Can't offer any help outside of the fact that this same issue plagues macOS upon a restart with Always-On for GlobalProtect until the system is unlocked via login, so not shocking to see this found its way into iOS either. 

[LCMember4417]

This is interesting we do have vpn on demand with certificate authentication with GP. When a user opens the app on IOS it will create a on demand VPN connection and only application specific domain name traffic is passed through GP and rest is local. So far we havn't heard any complaints  but not sure how many of them have 15.1 version. It was not easy to set this up but it took lot of time on MDM (workspace) to configure it right. Our IOS are DEP enrolled as well. Now this comments makes me to look at the iOS version of our users using this setup.

[ivormthomas]

When yo are connecting by domain name to send all traffic for just those domain names, that's not exactly an "Always On" VPN as the device would be allowed to communicate outside of the VPN when the VPN isn't established.  For data loss prevention and other content filtering, I want to tunnel all traffic except for traffic to Apple (keeps Geolocation accurate) and my Mobile Device Management platform.  Exempting the IPs doesn't work, DNS happens inside of the not yet established tunnel.  But, that does actually make me ask if I've tried "Exclude Domain" settings in the GW or not-- I think I have; my recollection is that the only thing that's honored after reboot is the mobileconfig file, that policy from the PAN gateway is applied after connection.  I'll retest.