cannot update iPads !

[kennysarmy]

Is it part of the ongoing speed issues ?

 

I can't even sign in to icloud on my test iPad - verified username/password correct on my PC.

 

Error is "Verification Failed : There was an error connecting to iCloud"

 

IOS 8.4 just stuck at "Update requested".

 

Pending app updates also stuck.

 

iPads going through a smoothwall who 1st line support looked at this issue quickly yesterday and call states:

 

ipad address is completely whitelisted - still not updating

added ip to source exceptions - no luck

 

tried browsing through the upstream proxy directly and it seems to be working ok

 

tcpdump shows nothing blocked

 

17.0.0.0/8 is in destination

[kennysarmy]

I've been able to update a test iPad using itunes - it downloads the whole 1.45 Gb update file ( for each iPad I update using this method )

 

I still am unable to get new apps or existing app to update - the waiting swirl appears for a few seconds then goes back to the "Get" or "update" button.

 

 

It used to all work fine....

[tmoon-mint]

Do you have a caching server on your network? This sounds to me like the iPads are trying to retrieve the update from a caching server but cant connect. This for example happens on an LA network when someone puts a caching server on their network, and all the devices across other subnets try to communicate with it and fail.

[kennysarmy]

Do you have a caching server on your network? This sounds to me like the iPads are trying to retrieve the update from a caching server but cant connect. This for example happens on an LA network when someone puts a caching server on their network, and all the devices across other subnets try to communicate with it and fail.

 

No caching server - but they are all going through the smoothwall.....but it's always worked in the past....

 

Just seems too much of a coincidence RM/SWGfL have been having so many internet problems and now this....

[Michael]

If the SWGfL is anything like other LAs, there could be numerous reasons as to why -

 

Many LAs still implement a proxy setup (at the core), with all schools sharing a pool of IPs, instead of their own dedicated IP. The theory being that Apple are throttling the number of requests permitted per public IP, but with all data encrypted, it's difficult to prove (just a theory).

 

The other possibility is a mis-configured Apple Caching server - again, if configured to serve 10.* instead of just your local subnet, this can also create problems, despite schools being VLANed off from one another. This is because Apple Caching servers need a public IP address to operate, so again, through the fault of other mis-configured Apple Caching servers, this could be another reason you're having problems.

 

In your case I would also try bypassing Smoothwall just for the IP of the iPad in question, just to prove that it's not the problem in the chain.

[Joanne]

I had to contact our internet provider (BTLS) and they have a fix in place for our network to talk to the apple servers... something about having a call open with apple and whatnot... I don't know what the fix IS... but I had to request something be done because mine were also doing this.

 

I think it's a port or something that needs opening? I could be wrong though!

[kennysarmy]

I had to contact our internet provider (BTLS) and they have a fix in place for our network to talk to the apple servers... something about having a call open with apple and whatnot... I don't know what the fix IS... but I had to request something be done because mine were also doing this.

 

I think it's a port or something that needs opening? I could be wrong though!

 

If the SWGfL is anything like other LAs, there could be numerous reasons as to why -

 

Many LAs still implement a proxy setup (at the core), with all schools sharing a pool of IPs, instead of their own dedicated IP. The theory being that Apple are throttling the number of requests permitted per public IP, but with all data encrypted, it's difficult to prove (just a theory).

 

The other possibility is a mis-configured Apple Caching server - again, if configured to serve 10.* instead of just your local subnet, this can also create problems, despite schools being VLANed off from one another. This is because Apple Caching servers need a public IP address to operate, so again, through the fault of other mis-configured Apple Caching servers, this could be another reason you're having problems.

 

In your case I would also try bypassing Smoothwall just for the IP of the iPad in question, just to prove that it's not the problem in the chain.

 

I've raised a call with RM - I won't hold my breath!

[kennysarmy]

A technician has connected his personal iPhone to our wi-fi and cannot sign in to iCLOUD - if he uses his 3G connection it's fine.

 

[kennysarmy]

I had to contact our internet provider (BTLS) and they have a fix in place for our network to talk to the apple servers... something about having a call open with apple and whatnot... I don't know what the fix IS... but I had to request something be done because mine were also doing this.

 

I think it's a port or something that needs opening? I could be wrong though!

 

RM did indeed to confirm that some ports were required to be opened on their firewall to allow iPads to update.

 

I remember when we originally had some iPads at school we requested some changes and all worked well, however some recent changes to our DHCP scopes and BYOD wireless networks meant that the original IP range they had the firewall changes set for no longer are applicable.

 

Yesterday they made the necessary changes to the new IP range....

 

But as of this morning, 24 hours later, no IPads here are able to install new Apps or update existing ones

 

Is there anyway to test that RM have done the right changes on their firewall....

 

I can't even sign in to iCloud on the IPads - yet it's fine on my PC

[localzuk]

Easiest thing to do is log a call asking for a full list of firewall rules in place for your school. Then compare with the Apple required list.

 

I do this periodically, and get old rules removed if they're not needed any more.

[kennysarmy]

Easiest thing to do is log a call asking for a full list of firewall rules in place for your school. Then compare with the Apple required list.

 

I do this periodically, and get old rules removed if they're not needed any more.

 

Might have to....

 

Currently:

 

If I click on Settings -> iCloud I get the error message : Verification Failed , There was an error connecting to iCloud.

 

When I try and update apps - I click the "UPDATE" button but it immediately returns back to the "UPDATE" button.

 

I've also factory reset another iPad and during the setup process it fails "Could NOT Activate iPad...

Your iPad could not be activated because the activation server cannot be reached."

 

 

So annoying....

[howartp]

Since iOS 9 came out last week, our beta testers (aka those who ignore the warning on staff & student noticeboards not to update) have had several problems with 'verification failed' errors.

 

We did install a caching server internally over the summer, which is serving apps fine and hasn't affected iOS 8.* since it was installed. It's only serving 192.168.*

 

Does anyone know of any server / port / URL changes to Apple with iOS 9 that I need to add to our Apple Bypass filter rules in smoothwall?

 

Peter

[Bigbird7]

Easiest thing to do is log a call asking for a full list of firewall rules in place for your school. Then compare with the Apple required list.

 

I do this periodically, and get old rules removed if they're not needed any more.

 

Can someone give me a link to the Apple required list?

[Arthur]

Can someone give me a link to the Apple required list?

 

https://support.apple.com/en-gb/HT201999

https://support.apple.com/en-gb/HT203361

 

albert.apple.com
ax.init.itunes.apple.com
ax.itunes.apple.com
ax.phobos.apple.com.edgesuite.net
deimos3.apple.com
gg*.apple.com
gs.apple.com
itunes.apple.com
mzstatic.com
phobos.apple.com

 

*.amazonaws.com
*.symcb.com
*.symcd.com
evintl-ocsp.verisign.com
evsecure-ocsp.verisign.com