We have a large number of new iPad Air's for our School, which are all failing to install their iOS updates. The error message is
"Unable to Verify Update.
iOS 7.1 failed verification because you are no longer connected to the Internet."
The internet connection is fine.
The download of the iOS update happens properly, and Safari has no troubles getting pages *while* the verification process is attempted.
I have been through the following:
Forgotton Wifi network and reconnected.
Reset Network Settings (Settings -> General -> Reset -> Reset Network)
Factory restore using iTunes
The problem I am trying to solve is using Over The Air updates. I am well aware that connecting an iPad to a computer with iTunes on it will do the job, but that isn't a solution that will work for us, as the teachers *do not have* computers to connect their ipads to. Nor is bringing them in to a central area a viable alternative, as they are geographically disparate. I need to fix this specific issue, and get them working wirelessly.
Two thoughts occur to me:
The iPad needs a valid iCloud account (although a test ipad from the same batch but connected to a different network did not).
The School firewall and content filter is blocking some portion of the update process.
We put another iPad on a fixed IP address, and removed all firewall restrictions for that IP address which allowed the update to work, so I'm concluding something in the firewall is blocking the update process.
I have run a packet capture on the firewall's interface provided for the school network, and have seen many connections to apple.com, akamai.com and amazonws.com. I have whitelisted *.apple.com in the firewall, but am quite reluctant to whitelist the whole of the others.
Hence, I'd like to narrow down which sites the iOS update process uses, so that I may open specific holes for those services.
Googling generally, and searching the Apple Support knowledgebase not been entirely productive, except to produce a handful of apple sites.
So I found the problem, and it was to do with the web filtering software on our Juniper SRX 650 firewall.
Basically, the UTM portion of the firewall grabs the packets responsible for opening connections, and inspects them, but lets the rest of the packets involved in the connection through. This means packets arrive out of order. Not normally an issue, as they are reassembled by the target host to form a complete request.
However, certain systems can be configured to reset connections if they do not receive the packets initiating a connection *first*. Since our firewall was holding these first packets for inspection, this did not happen, and the server responsible at apple sent a connection reset - terminating the update process on the iPad.
We had to exclude gs.apple.com from the web filtering entirely, despite having *.apple.com on the filter's whitelist. It seemed that this still introduced the delay in the connection-opening packet.