Apple Caching Server Authentication Problems with SWGFL

[ICT_GUY]

Our Mac mini that is set up as a caching server is failing to set up an SSL connection through our SWGFL internet connection. The answer from SWGFL is an ever helpful "Nah can't be done mate".

 

It has been suggested that we get a domestic grade connection purely for the macmini without filtering.

 

Our ipads and server have their own vlan and transparent proxy on it.

 

My question is, can I connect the macmini to the unfiltered domestic wired connection for internet access and to the wireless to farm out updates as has been suggested? The ipads would still use the filtered connection.

Edited September 23, 2015 by ICT_GUY

[ICT_GUY]

I am starting to think that I have asked a very stupid question or nobody knows the answer. I am going to go with the stupid question.

 

Any input appreciated.

[markwilfan]

Is this not what the unfiltered smart cache is for? You should be able to request access to it for an swgfl ip through the support desk

[Brimstone]

@ICT_GUY....

 

You could have a look through this blog from Fraser Hess who goes into detail on configuring this...

 

Fraser Hess: Caching Server: Enterprise Edition

 

SSL connections are unlikely to be supported because the App Store needs to be able to see your Caching Server and point iPads back to this when they request an update, If you used an unfiltered connection for the Mac Mini and kept the iPads on the filtered connection this would work in practice by configuring the networks you want the caching server to talk to but without knowing your network in detail this could be problematical..

[free780]

Don't you need a unique external ip for the caching server to work?

[ICT_GUY]

This is what I was told.

 

I’ve had a look at this. Basically the issue is that apple caching servers can’t interoperate with an internet service that has any NAT rules etc upstream. Here is a support article on the matter buried deep within Apple’s support :

 

https://support.apple.com/kb/PH15443?locale=en_US

 

The key bit is “The Caching server supports clients with OS X v10.8.2 or later and iOS 7 or later, and requires that clients share the same public IP address behind a NAT.”

 

As we filter your internet upstream in the proxy farm there is a whole host of NAT rules in place. So it just won’t work with any ISP that filters your connection upstream. (the technical forums are littered with people having NAT issues with various ISPs)

 

The only way it would work is for you to buy a smoothwall type local filtering device, and for us to provide a raw unfiltered connection to the internet that bypasses the proxy farm but goes through our firewall. We can do that but it will cost whatever the licences for the local device are (circa 3-4k per year I guess).

[Michael]

This is what I was told.

 

I’ve had a look at this. Basically the issue is that apple caching servers can’t interoperate with an internet service that has any NAT rules etc upstream. Here is a support article on the matter buried deep within Apple’s support :

 

https://support.apple.com/kb/PH15443?locale=en_US

 

The key bit is “The Caching server supports clients with OS X v10.8.2 or later and iOS 7 or later, and requires that clients share the same public IP address behind a NAT.”

 

As we filter your internet upstream in the proxy farm there is a whole host of NAT rules in place. So it just won’t work with any ISP that filters your connection upstream. (the technical forums are littered with people having NAT issues with various ISPs)

 

The only way it would work is for you to buy a smoothwall type local filtering device, and for us to provide a raw unfiltered connection to the internet that bypasses the proxy farm but goes through our firewall. We can do that but it will cost whatever the licences for the local device are (circa 3-4k per year I guess).

 

Or why don't you configure a static IP on your Apple Caching Server, then the SWGFL can create a rule so only that IP can bypass the proxy and filtering etc...

 

Buying into another connection really defeats the objective and is hardly good value for money. If your ISP at home told you this, or words to this affect, you'd move and I see no reason why a school should be any different.

[biz]

This was one of (many) reasons we didn't renew our SWGfL contract...

[Brimstone]

Having worked with a number of schools and Link2ict in Birmingham on this very issue with Caching Server, this is what we did...

 

As Caching Server 2 now lets you create a rule so only clients from the local subnet can connect and download data locally, I can share the following with you;

 

https://help.apple.com/serverapp/mac...F-870CB0FADCDB

 

The school had to set up the following with the LA so that they could point devices back to the schools Caching Server;

 

 

 

1. TXT DNS record created by the caching server also needed to be added to the BGFL Core DNS Servers as well as our own.
   
   
2. The ACL on the Cisco switch needed to allow the subnet for the proxies.
   
   
3. The proxy IP range was added to the caching server, I'm not sure this one was necessary but have added it just to be sure.
   
   

 

I also used the guide below from Fraser Hess to help the school and LA about ports being used and subnets required to be created;

http://blog.fraserhess.com/2013/11/c...-server-2.html

http://blog.fraserhess.com/2014/10/c...l?view=classic

 

Fraser also has a very useful book on the iBooks Store on all things Caching Server related..

 

Hope this can help you.

 

 

 

[badbot39]

On our yhgfl we had problems with the caching server as memory serves they share the same 2 IP addresses amongst schools so the caching server had problems staying on the same IP to download we were convinced we were pulling in caching info from other schools in the area at one point, the logs showed this happening as you pinged one address the caching server attempts to lock onto it but then it switches. I may be out of date and will read brimstones post with intrest.